Node.js: Initial experimental implementation of HTTP/2

[andrewbarba]

https://github.com/nodejs/node/pull/14239/

[BinaryIdiot]

I'm curious what will happen with the existing `http2` module. Will the http2 support get rolled into `http` or will `http2` remain separate and simply overshadow the npm module?

Also, is there a roadmap between what they expect that needs to be done to take it from where it is today to non-experimental, production ready? Granted I'm sure testing and bug squishing is part of it but I'm curious to know if there are specific goals they want to accomplish before final exposure.

Nice job all around on an initial release! I'll definitely take some time to play with it over the weekend :)

[tannhaeuser → BinaryIdiot]

There's also the 'spdy' module for http2 despite the name. It's what express.js supports for HTTP/2.

[1]: https://github.com/expressjs/express/issues/2364

[gbuk2013 → tannhaeuser]

I tried that before but it is very slow compared to native https module [1]

In the end though I added Nginx to my app container to be an HTTPS2 proxy and to serve static files instead - much better performance :)

[1] https://github.com/spdy-http2/node-spdy/issues/304

[tannhaeuser → gbuk2013]

Yes, but that kind of setup doesn't give you HTTP/2 server push so gives you hardly any benefit over HTTP/1.1, does it?

[gbuk2013 → tannhaeuser]

I was interested in multiplexing and I got that, as well as a big increase in performance serving static content.

[spankalee → tannhaeuser]

You can push by sending Link/preload headers, which will be turned into requests by the proxy.

[coldtea → tannhaeuser]

Push is hardly the biggest benefit of HTTP/2 over HTTP/1.

[simlevesque → BinaryIdiot]

> will `http2` remain separate

That's how it is with the `https` module so I bet that's what will happen.

[BinaryIdiot → simlevesque]

Oh good point I actually forgot `https` was separate. Forgive my ignorance but how does SSL work with http2? Will there also be an https2? I haven't actually played with http2 yet and this gives me a good excuse to.

[reificator → BinaryIdiot]

HTTP 2 has a defacto requirement of SSL to function.

Technically, it's not required by the standard. However every existing implementation does require it, with several vendors claiming they will never support HTTP 2 without encryption.

[daurnimator → reificator]

> However every existing implementation does require it

lua-http does not. https://github.com/daurnimator/lua-http/

Though the client won't auto negotiate http2 without TLS (yet... https://github.com/daurnimator/lua-http/blob/0b54603bfc132dc...), you have to tell it to do so explicitly.

[reificator → daurnimator]

I was debating putting in a disclaimer that I don't know all the existing implementations, but I was posting from my phone so I skipped it.

Thanks for both links, that's good information.

[Matthias247 → reificator]

If you insert "browser" between "existing" and "implementation" then it's correct. Most libraries also support unencrypted HTTP/2. E.g. nghttp2 (as used here in node.js, and also used by others like apache and curl) supports unencrypted connections. My own library for C# (https://github.com/Matthias247/http2dotnet) does too. The Go library might be a little bit of a special case, as it actually supports it, but the required functions are (or at least were) not exposed in the standard libraries http package. They should however be available in the x/net/http2 package.

[reificator → Matthias247]

Yep, I was typing on my phone and left out the "that I know of" disclaimer.

Good info, and thanks for the link.

[manojlds → reificator]

Every browser vendor I suppose, not every client.

[BinaryIdiot → reificator]

Oh good to know. I need to read up more on this. Thanks!

[trevyn]

Mmmmm... I'd rather see QUIC support -- A lot of Google -> Chrome traffic is served via QUIC, and Google, until very recently, had the only production-ready QUIC server. (Apparently Litespeed just added QUIC last month.)

[Matthias247 → trevyn]

QUIC has not yet been fully standardized. If you integrate a current draft you risk that your claimed QUIC support is broken 1 year from now. Google risks that, because they control all parts of the system (services & brower).

However I generally agree that HTTP/2 might only be short-term milestone on the way to HTTP over QUIC, as only this really fixes head-of-line blocking and therefore maybe justifies the increased implementation complexity better than HTTP/2.