[Libwebsockets] Do we have plan to support web socket over http2 client on libwebsockets.

zhang guojun guojunzhang1981 at gmail.com
Tue Sep 18 18:40:07 CEST 2018

Hi Andy,

Thanks for the quickly reply and very detail explanation.
In my case, there is a manage server to manage various network device. Right now we are using websocket as the transport tunnel, but as we know, we can see head-of-line-blocking issue.
So I consider the websocket over h2, in this way,  we can reuse some of the existing code. We may loss a little bit bandwidth compare to raw websocket, but it still can acceptable.
I go through the ws-over-h2 draft, the technology is flawless and you already implement server side code. In your perspective, what’s the reason the draft haven’t been a RFC? 

I’m also considering to use H2 directly.
BTW, does libwebsockets support SERVER PUSH and POST?


> On Sep 14, 2018, at 5:57 PM, Andy Green <andy at warmcat.com> wrote:
> On 15/09/2018 02:10, zhang guojun wrote:
>> Dear libwebsockets developers.
>> I’m glad to see libwebsocket support websocket over http2 server, do we have any plan to support web socket over HTTP2 client?
> Yeah, but not immediately.  H2 client is working (including multi client stream coalescing into one h2 connection) for HTTP GET already, just not the ws-over-h2.
> - I don't personally need it atm.  There's a really big benefit implementing server side as lws already has, if your client is a browser with it implemented.  Once the TLS + h2 is up for fetching html / css / js, an additional ws connection can be established inside the h2 connection, and start sending data, in just one RTT.  It only benefits clients that are opening multiple streams on the server... if the client just opens the one ws connection, it still has to do the TLS and start the h2 connection from scratch, so there's no advantage for that case.
> - It's not a small subproject... it interacts with both h1, h2 and ws roles / parsers and h2 needs all stream tx initiated from the h2 round-robin scheduler.
> - Aside from the Chrome browser developers who contacted me while we mutually used each other's implementation for testing, IIRC you're the first person to acknowledge the existence of even the server work.
> - Although the draft RFC is small and unlikely to change, it's not offical yet (it seems just a matter of time though)
> - Implementation status outside of Chrome (it's in Canary 67+ if you enable special flags) is opaque.  I asked twice on httpbis and just got ignored.  I guess they won't enable it by default until the RFC is formally accepted.  If you know the server has it and your non-browser client has it, you don't care about browser status though.
> Of course if someone wants to pay my consultancy rate for the couple of weeks it would take I could get religion about it.
> -Andy
>> Thanks
>> Guojun
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list