The spec is available at https://http2.github.io/

This project may be of use for the client side of things: <https://github.com/lukasa/hyper> (apparently MIT licensed).

I'm happy to talk about bringing hyper's HTTP/2 layer into http.client. It's worth noting that at this point I have no current plans to build a server into hyper, though if there was interest in using hyper as a baseline then I could take a swing at it.

+1 to the adding the support for HTTP/2. I would personally like to see a few things happen before that though (which I've been putting some effort into as i can)

+ refactor http.client to cleanly separate transport from application protocol level
+ figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface)
+ full HTTP/1.1 support. Given (as i understand it) HTTP/2 is largely an extension of HTTP/1.1 it doesn't make much sense to me to implement the latter before the former.

> figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface)

I've been thinking about this a lot with hyper, and I'm about to start work on it (having just finished an alpha implementation of HTTP/1.1). My current plan is to try out a proxy object pattern, but you should feel free to use the hyper code as a leaping-off point for some experiments into how to do the swapping.

@Cory: my own plan was to use your implementation as the baseline and add server support. If you take a crack at it that would be great!

@demian.brecht: I don't know when, but certainly that we will add in aiohttp HTTP/2 support. If your implementation is enough modular, we could use some stuff like we did with urllib and HTTP/1 support.

I spoke to some people after my PyCon talk about this, and agreed that it would be a good idea to split out the framing and HPACK stuff from hyper to make it easier for people like aiohttp to prototype.

The framing layer is already available from PyPI[0] and on GitHub[1], and I'm working on pulling the HPACK layer out right now[2], which should be available later today.

[0]: https://pypi.python.org/pypi/hyperframe
[1]: https://github.com/Lukasa/hyperframe
[2]: https://github.com/Lukasa/hpack

Why not to use HTTP parser from Nginx ? I mean write binding using Cython.

AFAIK, Nodejs already done that.

It is fast, and fully spec-compliant http-parser.

Even if HTTP2 is a standard, it looks a little bit more complex than HTTP 1.1. It would be nice to start with a package on PyPI to keep fast evolution, and then wait until the API is stabilized before we put anything in the stdlib.

Or maybe we should start with a "subset" of HTTP2.

By the way, the issue title is "http package should support HTTP/2". Are you talking about the http client or client+server? I suggest to start with the client.

It occurs to me that I should update this issue to mention that the HTTP/2 parser I spoke about above now exists, and has existed for some time, as hyper-h2. It's available on PyPI: https://pypi.python.org/pypi/h2

It's fully spec-compliant, and already used as the basis for HTTP/2 implementations in mitmproxy, Twisted, and hyper itself.

And now there's https://pypi.org/project/httpcore/ which wraps h2 and h11 into a single, low-level API.