Bug #74387 for Net-Async-HTTP: SPDY or HTTP/2 support

Wed Jan 25 14:04:49 2012 TEAM [...] cpan.org - Ticket created

Subject:

SPDY support

Would be nice to have SPDY support now that Chrome isn't the only major browser to support it - Firefox support started in 11.0, albeit disabled by default. https://bugzilla.mozilla.org/show_bug.cgi?id=528288 Haven't looked at the client side much, but for the serverside implementation a 1.0+ version of OpenSSL with a patch to support the alternative method extension was needed for 'full' support. There's also a workaround in that the server can send a header suggesting upgrade to SPDY (at least this was the case in draft2, that wording is gone from draft3 but so are a lot of other important things and draft2 appears to match the serverside support seen in the wild), so if the majority of SPDY-enabled servers are doing that already then it should work with any old ssl version - will check and report back when I'm not on a train. When I get around to uploading them to CPAN, the Protocol::SPDY and Net::Async::SPDY modules may help for this. Not aware of any other Perl implementations at this time.

Fri Mar 28 13:00:51 2014 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Subject:

SPDY or HTTP/2 support

I understand the focus is on the HTTP 2.0 spec these days http://http2.github.io/ Maybe we should look into that? -- Paul Evans

Fri Mar 28 13:00:51 2014 The RT System itself - Status changed from 'new' to 'open'

Fri Mar 28 13:01:09 2014 leonerd-cpan [...] leonerd.org.uk - Subject changed from 'SPDY support' to 'SPDY or HTTP/2 support'

Fri Mar 28 19:28:14 2014 TEAM [...] cpan.org - Correspondence added

On Fri Mar 28 17:00:51 2014, PEVANS wrote: Show quoted text

> I understand the focus is on the HTTP 2.0 spec these days > > http://http2.github.io/ > > Maybe we should look into that?

Yeah, next version of Protocol::SPDY has a version parameter to the constructor: version => 'http2' is the current draft, version => 'spdy/3' for the commonly-supported SPDY3 (should be compatible with firefox etc.), and you pick one by providing the usual NPN list on the SSL negotiation, typically with https as the last option for HTTP/1.1 fallback. Before I release that I'll add in a Protocol::HTTP2 wrapper class (same as Protocol::SPDY but ->new defaults to version => 'http2' instead of 'spdy3'). Protocol's still very much in flux, but if this is something that is disabled by default maybe that'd be easier for people to play around with. In terms of integrating this into Net::Async::HTTP, much of the old HTTP/1.1 semantics go away: headers can be sent at any time, rather than initial and trailing headers, body content is delivered in frames (much like chunked encoding). There's also push frames (and now the ability to promise that you're going to push frames as well), flow control via the 'window' frames, and a priority option... suspect a subclass of the Net::Async::HTTP::Protocol class might be a good start?

Wed May 07 08:44:52 2014 TEAM [...] cpan.org - Correspondence added

Seems that someone has just uploaded a Protocol::HTTP2 - might be a good candidate for NaHTTP support. It's based on the h2-12 draft, which is the latest implementation draft published a few days ago. Shame the API is so different from my version though :(