Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

HTTP/2 support #423

Open
kraih opened this Issue · 16 comments

6 participants

@kraih
Owner

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

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

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.

@kraih
Owner

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

@kraih
Owner

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

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

We need more volunteers to work on this.

@dvinciguerra

I can help!

@kraih
Owner

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

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
@kraih
Owner

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.

@vlet

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

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

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.