Skip to content

HTTP/2 #423

Open
kraih opened this Issue Dec 2, 2012 · 32 comments

9 participants

@kraih
Owner
kraih commented Dec 2, 2012

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.

@kraih
Owner
kraih commented Dec 2, 2012

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.

@kraih
Owner
kraih commented Dec 16, 2012

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.

@ChinaXing

+1

@derbrown
derbrown commented Apr 2, 2014

👍

@kraih
Owner
kraih commented May 30, 2014

The current version of the HTTP/2 spec terrifies me, think we'll wait with this as long as we can.

@kraih
Owner
kraih commented Jul 6, 2014

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.

@kraih
Owner
kraih commented Jul 7, 2014

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.

@kraih
Owner
kraih commented Dec 8, 2014

We need more volunteers to work on this.

@dvinciguerra

I can help!

@kraih
Owner
kraih commented Dec 8, 2014

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.

@kraih
Owner
kraih commented Dec 8, 2014

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.

@kraih kraih changed the title from HTTP/2.0 support to HTTP/2 support Jan 7, 2015
@kraih
Owner
kraih commented Feb 19, 2015

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.

@kberov
kberov commented Feb 19, 2015

👍

@vlet
vlet commented Apr 1, 2015

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

@kraih
Owner
kraih commented Apr 1, 2015

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

@rwx-zwx-awx

Up ;) Would be great to have this implemented :)

@kraih
Owner
kraih commented Nov 21, 2015

This feature depends on #876.

@kraih
Owner
kraih commented Dec 15, 2015

This feature also depends on #888.

@s1037989
s1037989 commented Jan 7, 2016

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.

@kraih
Owner
kraih commented Jan 7, 2016

Sadly we are already pretty far behind with this.

@kraih
Owner
kraih commented Jan 7, 2016

Honestly, i think unless we find a sponsor for this feature, it will take a very long time to get it production ready.

@kraih
Owner
kraih commented Jan 7, 2016

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.

@s1037989
s1037989 commented Jan 7, 2016

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?

@kraih
Owner
kraih commented Jan 7, 2016

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.

@kraih
Owner
kraih commented Jan 12, 2016

After the very successful hackathon last weekend, i think 6 months is a very realistic timeframe.

@kraih
Owner
kraih commented Jan 13, 2016

For learning more about HTTP/2, i recommend these two free ebooks.

https://www.nginx.com/http2-ebook/
http://daniel.haxx.se/http2/

@kberov
kberov commented Jan 13, 2016

👍 Thanks for the links!

@evoyy
evoyy commented Jan 26, 2016

I would be happy to sponsor some dev time towards this.

@kraih kraih changed the title from HTTP/2 support to HTTP/2 Feb 17, 2016
@kraih
Owner
kraih commented Mar 1, 2016

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.

@kraih
Owner
kraih commented Mar 1, 2016

We do not have anyone from the core team working on this though, and need volunteers. My current estimate for reaching milestone 4 with a full-time programmer would be 2-3 months.

@kraih kraih referenced this issue Mar 1, 2016
Closed

ALPN #888

@kraih
Owner
kraih commented Mar 1, 2016

In the meantime, you can of course deploy Mojolicious applications with a reverse proxy that supports HTTP/2, such as NGINX. https://www.nginx.com/blog/nginx-1-9-5/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.