mojo
mojo copied to clipboard
mojolicious
HTTP/2 and HTTP/3
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.
http://tools.ietf.org/html/draft-ietf-httpbis-http2-00
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
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).
Perhaps I'm naive, but I feel like if Mojolicious was first or among the first to release HTTP/2 support that it might help it to gain some attention and even many more new users.
Honestly, i think unless we find a sponsor for this feature, it will take a very long time to get it production ready.
I imagine this might become a bigger topic once there are HTTP/2 only servers on the web, and folks want to access them with Mojo::UserAgent.
What is needed from a sponsor? I don't have a ton of connections but I'd be happy to spread the word as best I can, as I already do for Mojolicious. Everyone in St. Louis, MO, USA is at least now aware that Mojolicious exists and is the greatest thing since sliced bread. :D
I'd also like to get my employer involved, so there's that...
Is there anything more that a sponsor can do than provide money? How much money? What is the process for this? Is there perhaps a not-for-profit entity for the purpose of tax deductible contributions (in the USA and/or otherwise)? I could look into establishing a not-for-profit organization in the USA if interested, I'm unaware at this point what the requirements of it are.
What would be the timeline to release a first version of this branch?
Realistically, i think it would take a good full-time programmer between 6 and 12 months to finish this feature. Currently there is no formal process, but if one or more interested companies step up, i'm sure we can change that pretty quickly.
There are a few milestones to reach, 1) protocols like HTTP/1.1 and WebSockets need to become pluggable (#876), 2) we need ALPN protocol negotiation (#888), 3) proof of concept implementation of the HTTP/2 protocol with an existing CPAN module like Protocol::HTTP2, 4) optimized custom implementation of the HTTP/2 protocol, 5) advanced features such as stream prioritization and server push.
After the very successful hackathon last weekend, i think 6 months is a very realistic timeframe.
For learning more about HTTP/2, i recommend these two free ebooks.
https://www.nginx.com/http2-ebook/ http://daniel.haxx.se/http2/
ALPN support is done (#888), and pluggable protocols almost finished too (#876). I think a proof of concept HTTP/2 implementation might be possible now.