[Libwebsockets] http2 work on lws

Andy Green andy at warmcat.com
Sun Oct 12 09:20:30 CEST 2014

Hi -

Recently I started on HTTP2 support in lws.

HTTP2 itself seems to be pretty well-defined already


It has a critical companion spec for HPACK, the header compression scheme


Websockets over HTTP2 is in less good shape.  An RFC exists


but the "Framing" section says "to be written".

Google have something for Websocket over SPDY, which was the basis of HTTP2


but it's unclear if it has any momentum.

At any rate, in the same way lws requires and is dependent on a certain level of HTTP 1.x support to make websockets work, whatever happens with websocket implementation on HTTP2 it will definitely require even more support for generic HTTP2 operation in order to use websockets on top of it.  For that reason I started with the server-side HTTP2 work.

Today's http2 support in lws can work with non-SSL connections, negotiate the HTTP2 upgrade with the HTTP2 client, and send test.html, using nghttp2 HTTP2 client, and keep the connection up.  Reproduce with lws 917f43ab82138 and

nghttp -nvu http://localhost:7681/index.html http://localhost:7681/test.html

That's quite minimal but

 - it does it while still being able to serve HTTP1.X and websocket from the same server

 - most of the framing handling for both directions is plumbed in cleanly

 - he has a very compact huffman decoder state machine for the compressed header decode, it's only 576 bytes of table and a couple of lines of code to decode all the standard headers; variable bit coding stuff is also implemented for both directions

 - SSL support should be very little extra code once non-SSL works, but most OpenSSL out there are too old to use the required new autonegotiation stuff in new OpenSSL

 - Almost all the HTTP2-related code is turned off by default to reduce bloat for people who don't care, you can enable in cmake like -DLWS_WITH_HTTP2=1

 - Getting anything working means minimal support for mux is included.  HTTP2 will become very attractive I think because all a browser's logical connections to a server can be limited to one TCP/IP connection using the baked-in connection muxing.

There's still plenty missing but this is the first important milestone it can interoperate at all using real HTTP2; HTTP2 is different enough that was quite a lot of work already.

One major change that has become clear is we need to update how we generate headers for http in lws, including in the user code.  I introduced four new APIs and updated the test-server to use them.  These allow headers to be managed transparently by lws without the user code needing to know if he's getting an HTTP1.x or HTTP2 connection.  These are mentioned in the current changelog.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libwebsockets.org/pipermail/libwebsockets/attachments/20141012/377dc33a/attachment.html>

More information about the Libwebsockets mailing list