NG
NG copied to clipboard
nodejs
HTTP2 (and maybe WebSockets)
One of our more vibrant threads is about adding HTTP2 to core.
https://github.com/iojs/io.js/issues/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.
@mikeal such user modules might benefit a lot from public C++ Streams API, should I open an issue for it here or somewhere else?
@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?
@mikeal already did it in https://github.com/iojs/io.js/issues/921, thanks!
Had a bit of dicussion about http2 in https://github.com/iojs/io.js/pull/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
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:
Would the new module be built off of an existing userland module, or would it be built from scratch?
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.
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 :)
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.
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.
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
would like to just make a shout to @mscdex because https://github.com/iojs/io.js/pull/1457 is awesome. hopefully it would pave the future for http2 support. :D:D
would like to just make a shout to @mscdex because iojs/io.js#1457 is awesome. hopefully it would pave the future for http2 support. :D:D
I have the same hope :)
+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.
Ping on this... I would love to get this discussion moving again. I have my issues with how http/2 was designed but having http/2 in core would be good.
Koa appears to want http2 included:
Features for HTTP2 support can still go into Koa v1. The only problem is that if it's not in require('http') or require('https'), we're not going to include it in Koa.
Another note, Indutny's node-spdy has a pretty significant decomposition of the HTTP server (see the spdy-transport project that's he's spun out). With talk of merging HTTP + HTTPS codebases also happening (not complete to my knowledge?), node-spdy could contribute to that in a significant and gainful way.
Kind of surprised that http/2 still isn't in the core! Aren't we behind the curve by now?
Actively working in it. On Jun 17, 2016 9:34 PM, "Arthur Blake" [email protected] wrote:
Kind of surprised that http/2 still isn't in the core! Aren't we behind the curve by now?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nodejs/NG/issues/8#issuecomment-226921405, or mute the thread https://github.com/notifications/unsubscribe/AAa2eeTofgjlaSH4uIkfkEaUMKCOvAwwks5qM3VvgaJpZM4DpnEB .
Looks like Google are ready to pull the plug on SPDY but HTTP2 for node is not ready which is a worry ... http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html
I am really excited that HTTP/2 support will soon land in Core https://github.com/nodejs/CTC/issues/6 !
@c0b It will not. Preempting the follow-up question: I don't know, when it's ready.
@jasnell has said recently that he hopes to have it ready in the 8.x timeframe. Might be best to ask in https://github.com/nodejs/http2/issues.
I promise it's coming soon. @mcollina and I have discussed a schedule that has us opening the PR in mid to late June. There are quite a few line items to cross off first.