HTTP2 (and maybe WebSockets)

[mikeal]

One of our more vibrant threads is about adding HTTP2 to core.

nodejs/node#4

In the TC meeting today there was broad support for adding something to core but no clear confidence about what should be added.

I'd like to start looking at HTTP2 and related modules in the ecosystem, and well as write some new ones, so that we can advance this process and to try and have HTTP2 support in for NG if not sooner.

[indutny]

@mikeal such user modules might benefit a lot from public C++ Streams API, should I open an issue for it here or somewhere else?

[mikeal]

@indutny isn't the public C++ Streams API going in to 1.x soon anyway? should that just be an issue on iojs/io.js?

[indutny]

@mikeal already did it in nodejs/node#921, thanks!

[silverwind]

Had a bit of dicussion about http2 in nodejs/node#1101.

Because https is just a wrapper for http+tls and because http2 strongly encourages tls, we'd like to see http and https eventually being merged into a single http module. createServer then could take an option object with the new properties version (1 or 2) and tls (true or false) along with all other tls options.

Once http2 support in core is done, we should default to it. Defaulting to tls might be desireable too, but I have my doubts that this will be the primary use case for a while, given that most people don't terminate https directly on io.js nowadays.

The tls situation may change once letsencryt goes live, and if it proves good I might even suggest adding their API to the core. I think simple certificate management will be crucial for http2 adoption.

cc: @brendanashworth

[brendanashworth]

A strong +1 on much of what @silverwind is saying. HTTPS is a great feature of io.js and merging the two modules will lower the barrier to entry between them and cause less confusion. I don't know much about the HTTP2 spec, but if they are backwards compatible with eachother (i.e. an HTTP2 server can run HTTP1.1 requests), I would like to see HTTP2 by on by default by just upgrading your io.js version.

I'd rather not see letsencrypt explicitly in core, but I think a well-placed link in the documentation might lead to higher TLS adoption in general.

Related HTTP2 userland modules:

• summerwind/sasazka
• molnarg/node-http2

Would the new module be built off of an existing userland module, or would it be built from scratch?

[mikeal]

I agree that it would be better to unify the API and module endpoint for HTTP and HTTPS. However, the idea of "defaulting" to TLS is a little trickier than it sounds and probably not something we want to do. If you listen on 80 we should not default you to TLS, for instance. We should make it easier to write this correctly though, perhaps it should look something like this.

var http = require('http')
  , server = http.createServer()
  ;
server.listen(80)
server.listenSecure(443, {cert:cert})
server.secureForward(302) // redirect HTTP to HTTPS, optional HTTP code defaults to 302.

[mikeal]

I've started working on a new pure JS HTTP parser that does HTTP 1 and 2 and I've started to think about one of the more difficult components.

Because all requests are sent over a single socket that means that we now need a "group of streams" that are all being duplexed through another single stream. HTTP2 also supports prioritization of those individual requests, which we'll need an API for. The logic around back-pressure in this "group of streams" is going to be pretty tricky so I figured I should get people thinking about it now :)

[tellnes]

I've also started experimenting with an HTTP/2 implementation in pure JS.

Adding a listenSecure and and secureForward is on the verge of what I mean belongs in userland, but would be pretty nice. The best part of that proposal is being able to provide options like cert to the listen method instead of the server constructor.

[csulok]

Borderline offtopic, but maybe it adds to the perceived values / what should be userland going forward:

I've recently ran into the issue of running https server but also needing a redirect from http. That's easy enough when you run on default ports (443 with tls and 80 without), not so much with the same port though. A client I deal with chose :8220

The solution suggested elsewhere is something like this below, but I'd say function tcpConnection is not something that should be in userland. Ever.

https://gist.github.com/bnoordhuis/4740141

If it counts, this is +1 for secureForward and generally anything in that direction.

[silverwind]

Running both on the same port is a huge hack, and I think rightly so. A tcp port should only serve one protocol, it's how the internet was build. There's also this: https://github.com/mscdex/httpolyglot

[jonathanong]

would like to just make a shout to @mscdex because nodejs/node#1457 is awesome. hopefully it would pave the future for http2 support. :D:D

[mikeal]

would like to just make a shout to @mscdex because nodejs/node#1457 is awesome. hopefully it would pave the future for http2 support. :D:D

I have the same hope :)

[stanier]

+1 for HTTP/2 support

Joyent hasn't shown much interest in supporting HTTP/2 in node.js, but the fact of the matter is that the protocol is finalized and it is the future of HTTP, with the future being today. After reviewing RFC7540 and RFC7451, I understand why there has been hesitation and why external packages on npm have had trouble with implementation, but I also feel as though implementation is vital and very possible. Native support for HTTP/2 would (while not replacing them), allow for less reliance on WebSockets and better performance as a result.