Feature Request: HTTP2 about node

[JiangJie]

+1 for HTTP/2

[domenic]

I definitely agree that if HTTP 1.1 is in core then HTTP 2 should be in core.

[yorkie]

+1 for http2, that would be awesome.

[haoxins]

+1

[yosuke-furukawa]

+1

[nmn]

+1, but would also add a word of caution. That HTTP2 standard isn't quite finalized, and till that time, it makes sense for node-spdy to be the canonical way to add SPDY support.

[mikeal]

what exactly is this feature request for? is it for http2 support to be added to core or just for an work necessary for better support in userland to be added to core (I'm not sure what that would be).

[alwayrun]

+1

[yorkie]

I'm guessing @jonathanong is going to refer this forward project koajs/koala and here is a discussion about http2 and spdy.

[nmn]

I think he's asking for http2 support in core.

Again, I think that's a great idea, but the time is not right yet.

[jonathanong]

yeah this is for core support, though developing it as a userland module until all the committers agree on the implementation would be okay with me too.

[mafintosh]

whats the benefit of adding this to core instead of just having it live in userland?

[nmn]

I think eventually this should land in core. Node.js was ahead of the curve with it's core http module using http 1.1 when it came out. Once http2 standard is stable, support should ideally be added to core.

I think this is a low-level, fundamental feature that deserves to be in Core.

[defunctzombie]

Not a core issue IMO. A distribution issue.

[nmn]

Probably a little early to discuss this at all I guess. I think when the time comes, the best approach will feel obvious.

[liveinjs]

+1

[dconnolly]

+1

[defunctzombie]

Just make a module.

[ghostbar]

Can't see a win on making it part of core.

[ilanbiala]

HTTP should definitely not be a module, because that's one of the main features of core. That's what makes it so easy to put together a node app, and it's an advantage node has compared to other languages that separate it into a module.

[rlidwka]

HTTP should definitely not be a module, because that's one of the main features of core.

This "main feature" in node.js is useless. For example, I never directly use neither server (I prefer express module) nor client (I use request).

Of course we need a stable and well-maintained HTTP and HTTP2 implementations, but I don't see why it should be in core.

[ilanbiala]

If it's not in core, it should still be completely controlled by io.js, which is the same as being in core in my opinion.

[algesten]

Uhm. @rlidwka express uses http https://github.com/strongloop/express/blob/master/lib/application.js#L13 so does request https://github.com/request/request/blob/master/request.js#L3

[Fishrock123]

Support for this will be inherently necessary in the future.

HTTP/2 is landing in chrome 40 soon: http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html

(+1)

[indutny]

Ok, +1 from me. I'll start working on it after we'll figure out #589

[indutny]

cc @iojs/collaborators how does it look to you?

[micnic]

+1

[trevnorris]

HTTP2 is a CF if I've ever seen one. Basically TCP implemented in HTTP over TCP...

Anyway, IMO this should be an issue in http_parser not here. Though once properly implemented we'll have to expose additional JS APIs to support all the new HTTP2 features.

[bnoordhuis]

I dread the thought of adding HTTP/2 support to http_parser... It's already a near unmaintainable mess of twisty little goto statements, all alike.

[indutny]

@bnoordhuis yes. @trevnorris please no.

[trevnorris]

@indutny heh. further solidifies that HTTP2 support shouldn't go directly into io.js.

[nmn]

I think the problem is again that http/2 is not quite ready.
if the http module belongs in core, than so does the update to http2. I don't think of it as adding new functionality, but rather keeping up to date with standards.

if http2 support doesn't belong in core, then the http module doesn't belong in core either.

Plus I agree that bad code in http_parser shouldn't affect this decision.

[jonathanong]

what i care most about is that it's in the iojs organization so that it's deemed official. i don't want to support 100 implementations of HTTP2. there's already an http2 module for node as well as spdy.

being included in iojs/io.js or being a separate module as iojs/http2 is just a technical detail to me. i don't mind doing var http = require('http2'). though then i wonder if http as a whole could be a separate repo/module...

[brendanashworth]

From my point of view, once HTTP2 begins to be commonplace among browsers,
io.js should already have the module baked into core and relatively stable.
It should definitely not be userland - however until the proposal is ironed
out (or it already is?) I think it would make sense to have an NPM module
managed by the core team as a sort of "testing" and "boots on the ground"
development. It isn't in core yet so the developers wouldn't have to worry
about perfection and reliability, but stability would still be in mind for the
future.

Am Montag, 9. Februar 2015 schrieb jongleberry :

what i care most about is that it's in the iojs organization so that it's
deemed official. i don't want to support 100 implementations of HTTP2.

being included in iojs/io.js or being a separate module as iojs/http2 is
just a technical detail to me. i don't mind doing var http =
require('http2'). though then i wonder if http as a whole could be a
separate repo/module...

—
Reply to this email directly or view it on GitHub
#4 (comment).

[jasnell]

At the very least this needs to be explored. It's going to be a while before http/2 settles down enough to get broad adoption but getting this into core will make sense (perhaps within the year at least). Mixing it in with http_parser would simply be a mistake. I'd have to look at it in detail, but perhaps a better approach would be to look at incorporating one of the existing C implementations (e.g. https://nghttp2.org/) as an optional dependency. Either way, I'd say this is pretty low on the priority queue.

[gx0r]

Streams moved out of core. Not sure why http/2 should be in core unless there is a technical reason. Being in core essentially locks the module version to the io.js version.

[tellnes]

@llambda The questions is not if it should be developed inside or outside of core. The question is if it should be bundled or not with core like streams and http-parser are.

It will probably be developed outside of core like http-parser is.

[nmn]

@tellnes That makes sense. http2 can be developed seperately. But of course it should be bundled with core. (After it's production-ready.)

[Fishrock123]

Just because it can be developed outside if core doesn't mean it should be either. @indutny seemed to think he could do it quite nicely in core.

[mikeal]

There seems to be some confusion about what in/out of core means to different people.

I think a lot of the people closer to core are taking for granted the idea that all future stdlib modules will be built much like readable-stream, as a separate module available in npm that is packaged up and distributed with core as stream.

Any future http2 module would be built as a regular module for npm and once it had matured, if there was good reason to include it, it could be shipped with core. Going forward I don't think there will be any new modules developed within core unless they are exposing core specific functionality (vm, tracing, etc).

[piscisaureus]

A pure-js userland http2 module already exists: https://github.com/molnarg/node-http2.
Eventually we'd want this in core, with native parser support, but I think it'd be good to develop the c++ bits in userland first too.

[piscisaureus]

On a related note, I think websockets should be in core too.

[vkurchatkin]

so, are we talking about new http2 module or http2 support for http module?

[Fishrock123]

Any future http2 module would be built as a regular module for npm and once it had matured, if there was good reason to include it, it could be shipped with core. Going forward I don't think there will be any new modules developed within core unless they are exposing core specific functionality (vm, tracing, etc).

.

so, are we talking about new http2 module or http2 support for http module?

There has not yet been agreement on this.

The thing is, we'll get to a point at this rate where the http module does not represent http.

To avoid this, http2 should be in http; or else we should be un-shipping http altogether.

[mikeal]

The thing is, we'll get to a point at this rate where the http module does not represent http.

That future is a long way out, and we don't know enough about what the ideal http2 API looks like yet to make these kinds of decisions. http2 has a lot of new functionality but it's inconceivable that you could build a product on it any time soon without some kind of backwards compatibility on http 1.1. For some features that backwards compatibility could be a lot of work (think about the fallbacks in socket.io).

It's worth it to be cautious and take our time letting the ecosystem come up with novel approaches to these problems.

[madbence]

fyi, http2 finalized

[snostorm]

I guess the question is whether to try and "adopt" an existing HTTP/2 node solution or help spawn a new one (as a "blessed" optional package, initially experimental -- pending future stability), or just give it X more months to work itself out in the community and revisit the issue then.

I'd worry that a less efficient / poorly maintained repo becomes the de facto HTTP/2 solution on npm, especially with the excitement about the new technology. If that happens, and a lot of packages may tie in to that module a dependency. At that point we may be more limited to steer the project in a direction that might help bring it to eventual core quality. Although ... in open source, this tends to work itself over time anyway.

As an aside, although HTTP/2 (and the now retired SPDY) are both young, a lot of people are excited to start using them. We do have browsers out there using the standard now and doing so can provide some performance gains.

If you factor out the "new magic stuff" of HTTP/2, which people don't quite know how to best deal with well yet -- like pushing assets, there are still advantages to simply reusing the connection and having assets serve in parallel with the reduced overhead HTTP/2 offers.

[nmn]

I think the best way, if doable, would be to build on top of the existing http module to add http/2 functionality to it in a backwards compatible way.

Focus should be on keeping it stable rather than full http2 conformance.

Eventually it will reach 100% conformance with backwards compatibility that will be best for everyone.

That said, there are have been rumblings that the http module is currently enough of a mess to not be easy to build on top of. In that case a full re-write would be required anyway, in which case whatever works.

[indutny]

@snostorm what module do you have in mind?

[mikeal]

We discussed this at length in the TC meeting today. There is broad support for doing something but little confidence about what should be done. I'd like to continue this conversation in NG nodejs/NG#8 and close out this thread.

[Globegitter]

Has there been any update on this? Seeing as now all major vendors support HTTP/2 or are going to support it in the near future this would be a great time to start discussing this feature again.

https://github.com/molnarg/node-http2 is a working implementation btw.

[Fishrock123]

@Globegitter I think the conclusion last time is we should see what options are available for how we might best implement this. I know @indutny has worked on his node-spdy implementation a lot recently, which also supports HTTP/2. :)

[indutny]

Yeah, it is still a beta version though. I should find some time to fix last bug and do a release. But it is already working now, you may want to consider trying it out ;)

[Globegitter]

@Fishrock123 @indutny Happy to give node-spdy a spin as well. My first basic tests with node-http2 have been going well so far. Happy to share some tests etc.

[nmn]

i've been using this package in production on scribbler.co for more than a year. oops.

[NawarA]

Having iojs / node 4.0 support HTTP/2 would be a major victory...both in the press and for all end-users. HTTP/2 is now standardized in RFC 7540, and we can begin thinking about adding this as a standard feature (just like we support HTTP 1.1).

@indutny has done a lot of great work on node-spdy, the most popular SPDY / HTTP 2 library available to our community. While that lib may be considered beta, it none-the-less offers a great framework of code we can use to begin standardizing the now official modern protocol.

Personally, I'm happy to help any way, and I'm happy to test the alpha / beta versions of this on my service, which does hundreds of hits a second (a high IO service). We can then test and see the potential performance improvements that HTTP/2 will offer our community, and most importantly, the millions of end-users around the world that are effected by Node stacks.

+1 to supporting this. Happy to help. What are the next steps for supporting this feature?

[Globegitter]

@NawarA I am starting by updating some smaller open source projects/modules that seem to, if anything, just benefit from it. Also trying to move our dev environment at work to HTTP/2, generally trying to increase awareness that it is ready to use.