This repository has been archived by the owner. It is now read-only.

HTTP2 (and maybe WebSockets) #8

Open
mikeal opened this Issue Mar 4, 2015 · 23 comments

Comments

Projects
None yet
@mikeal
Member

mikeal commented Mar 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@indutny

indutny Mar 4, 2015

Member

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

Member

indutny commented Mar 4, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 4, 2015

Member

@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?

Member

mikeal commented Mar 4, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@indutny

indutny Mar 4, 2015

Member

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

Member

indutny commented Mar 4, 2015

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

@silverwind

This comment has been minimized.

Show comment
Hide comment
@silverwind

silverwind Mar 13, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@brendanashworth

brendanashworth Mar 14, 2015

Member

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?

Member

brendanashworth commented Mar 14, 2015

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?

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 14, 2015

Member

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.
Member

mikeal commented Mar 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 14, 2015

Member

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 :)

Member

mikeal commented Mar 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tellnes

tellnes Mar 17, 2015

Member

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.

Member

tellnes commented Mar 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@csulok

csulok Mar 17, 2015

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.

csulok commented Mar 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@silverwind

silverwind Mar 17, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@jonathanong

jonathanong Apr 21, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Apr 21, 2015

Member

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 :)

Member

mikeal commented Apr 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stanier

stanier Jun 4, 2015

+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.

stanier commented Jun 4, 2015

+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.

@boneskull boneskull referenced this issue in GraftJS/jschan Jul 24, 2015

Closed

protocol error w/ io.js 2.40 #36

@shinnn shinnn referenced this issue in BrowserSync/browser-sync Aug 18, 2015

Closed

HTTP/2 support #766

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jan 28, 2016

Member

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.

Member

jasnell commented Jan 28, 2016

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.

@rektide

This comment has been minimized.

Show comment
Hide comment
@rektide

rektide Feb 5, 2016

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.

rektide commented Feb 5, 2016

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.

@mscdex mscdex referenced this issue in nodejs/node May 17, 2016

Closed

HTTP/2 support #6814

@ericmdantas ericmdantas referenced this issue in sintaxi/surge May 18, 2016

Open

HTTP/2 support #212

@jasnell jasnell referenced this issue in nodejs/CTC Jun 9, 2016

Closed

HTTP/2 support in Core #6

@arthurblake

This comment has been minimized.

Show comment
Hide comment
@arthurblake

arthurblake Jun 18, 2016

Kind of surprised that http/2 still isn't in the core! Aren't we behind the curve by now?

Kind of surprised that http/2 still isn't in the core! Aren't we behind the curve by now?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jun 18, 2016

Member

Actively working in it.
On Jun 17, 2016 9:34 PM, "Arthur Blake" notifications@github.com 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
#8 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eeTofgjlaSH4uIkfkEaUMKCOvAwwks5qM3VvgaJpZM4DpnEB
.

Member

jasnell commented Jun 18, 2016

Actively working in it.
On Jun 17, 2016 9:34 PM, "Arthur Blake" notifications@github.com 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
#8 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eeTofgjlaSH4uIkfkEaUMKCOvAwwks5qM3VvgaJpZM4DpnEB
.

@tohagan

This comment has been minimized.

Show comment
Hide comment
@tohagan

tohagan Jun 22, 2016

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

tohagan commented Jun 22, 2016

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

@valera-rozuvan

This comment has been minimized.

Show comment
Hide comment
@valera-rozuvan

valera-rozuvan Sep 26, 2016

I am really excited that HTTP/2 support will soon land in Core nodejs/CTC#6 !

I am really excited that HTTP/2 support will soon land in Core nodejs/CTC#6 !

@c0b

This comment has been minimized.

Show comment
Hide comment
@c0b

c0b Apr 14, 2017

anyone knows that if the Node v8 in this April 2017 will have http2 in core?

c0b commented Apr 14, 2017

anyone knows that if the Node v8 in this April 2017 will have http2 in core?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Apr 14, 2017

Member

@c0b It will not. Preempting the follow-up question: I don't know, when it's ready.

Member

bnoordhuis commented Apr 14, 2017

@c0b It will not. Preempting the follow-up question: I don't know, when it's ready.

@joshgav

This comment has been minimized.

Show comment
Hide comment
@joshgav

joshgav Apr 14, 2017

Member

@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.

Member

joshgav commented Apr 14, 2017

@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.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 14, 2017

Member

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.

Member

jasnell commented Apr 14, 2017

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.

@abovedave abovedave referenced this issue in dadi/web May 23, 2017

Closed

🚧 [Do not merge] Add support for HTTP2 #167

5 of 6 tasks complete
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.