You can clone with
HTTPS or Subversion.
The final HTTP/2 spec is still at least 1-2 years away, but now that the first draft (based on SPDY) has been released, i believe we can at least start planning our implementation.
While details like the upgrade mechanism from HTTP/1.1 and mandatory TLS encryption are very likely to change, major features like multiplexing are pretty much a given, and will require some refactoring in Mojolicious.
I've been thinking about this a bit, and i believe a new layer (Mojo::Channel?) between connection management and high level transactions would make adding new protocols and dealing with multiplexing a lot easier.
Mojo::UserAgent -> Mojo::Channel::HTTP::Client -> Mojo::Transaction::HTTP
-> Mojo::Channel::WebSocket::Client -> Mojo::Transaction::WebSocket
Mojo::Server::Daemon -> Mojo::Channel::HTTP::Server -> Mojo::Transaction::HTTP
-> Mojo::Channel::WebSocket::Server -> Mojo::Transaction::WebSocket
Channels could combine all client_* and server_* methods from the transaction classes with the transaction management code of the user agent and daemon.
A good first step might be to move the transaction management code from Mojo::UserAgent to Mojo::Channel::HTTP::Client and Mojo::Channel::WebSocket::Client, that should be enough to figure out the right API and cause no backwards compatibility issues.
The current version of the HTTP/2 spec terrifies me, think we'll wait with this as long as we can.
I believe the original Mojo::Channel plan might also have also been a bit too ambitious, better start with something that fits into the current architecture, and work on abstraction once we have more experience.
The HTTP/1 upgrade mechanism can be ignored completely, browser vendors are not going to implement that (Firefox and Chrome have confirmed this in the working group), only valid handshake for negotiating HTTP/2 will be TLS with ALPN/NPN. So IO::Socket::SSL and a modern version of OpenSSL will be hard requirements.
Working Group Last Call. http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1563.html
We need more volunteers to work on this.
I can help!
The plans i've outlined above were a bit too ambitious, that extra layer of abstraction is not really necessary. I think a good first step would be to start with a prototype, using an existing implementation of the HTTP/2 protocol (perhaps Protocol::HTTP2). Then the focus can be on getting protocol negotiation right, with NPN/ALPN in Mojo::IOLoop::Client/Mojo::IOLoop::Server, and HTTP1/HTTP2 in Mojo::UserAgent/Mojo::Server::Daemon.
I'm actually not too concerned about the actual protocol implementation, that seems pretty straight forward, and more about the integration into our existing architecture.
Since browsers like Chrome already support HTTP/2, i think a good first milestone would be to add NPN/ALPN support to Mojo::IOLoop::Server with IO::Socket::SSL, and then just enough Protocol::HTTP2 glue code to Mojo::Server::Daemon for basic request/response handling.
The HTTP/2 spec was just finalized, and OpenSSL 1.0.2 with ALPN support has been released too. So theoretically nothing is stopping this feature anymore.
I don't familiar with Mojo internals, but i tried to implement glue code https://github.com/vlet/mojo/tree/vlet/http2-hacks
Protocol::HTTP2 API is not stable yet, so there is a opportunity to change it in a way, that will be convenient for Mojo
@vlet Thanks, that's a pretty decent proof of concept. The PSGI step should be avoided though, and the response might not be available right after the request event has been emitted (non-blocking operations in progress).