[Twisted-Python] HTTP/2 and Twisted

[Tristan Seligmann]

On Thu, 12 Nov 2015 at 12:46 Cory Benfield <cory at lukasa.co.uk> wrote:

> However, this may not work: in particular, some of the other classes in
> twisted.web may know altogether too much about HTTP/1.X: in particular, if
> they have the nerve to write directly to a transport we’ve got a real
> problem with this approach, as HTTP/2 does not allow naked writes on its
> sockets (all data is framed).
>

I'd like to point out a few things on this topic:

1) The Twisted project has already experimentally demonstrated the
imprudence of an approach that massively breaks backwards compatibility
with old APIs (even if it does this in concordance with the compatibility
policy, by adding a bunch of new things): see the defunct twisted.web2
project.

Realistically, if you say "hey people, twisted.web now has HTTP/2 support,
all you have to do is port all of your code and all of your libraries over
to these new APIs!", the response isn't going to be "great, I'll get right
on that!". It'll be "oh well, I guess I'll just throw an nginx reverse
proxy in front of my app to get HTTP/2 working" or "oh well, never mind
then".

A successful approach to introducing HTTP/2 into twisted.web needs to allow
for hooking up existing resources to an HTTP/2 (or actually, presumably
multiprotocol) server.

2) Having said that, it's not necessary for the HTTP/2 server to be
completely compatible with the current HTTP/1.x server in twisted.web. For
some things, this is just flat out impossible (I believe there are things
that HTTP/1.x allows, but HTTP/2 doesn't allow), and for other things it
just doesn't make sense (stealing the transport and writing stuff to it
yourself). However, we only need to support the common set of things that
people use in order to be usefully compatible; if you just have some
resources that aren't doing anything particularly crazy (like hijacking the
transport and writing directly to it, rather than via the request object),
you should be able to hook them up and have them work.

For anything that we *can't* support, it's okay for the HTTP/2 server to
just raise an exception or whatever; for anything that we can reasonably
support, but don't actually want to, it's okay to emit a deprecation
warning, and later an exception.

3) Having said *that*, there is widespread agreement that the existing APIs
(IResource, IRequest, etc.) have numerous deficiencies that should be
addressed. For example, the current interfaces don't allow for streaming
request handling, which obstructs implementing 100-continue support (among
other things).

We *do* need newer interfaces which hopefully improve on the new ones; I
don't really feel like I'm in a position to sketch out what these
interfaces should look like, but they should definitely take into account
the constraints of the HTTP/2 protocol, as well as the needs of application
code.

PS: I've used the pronoun "we" multiple times in this email for the sake of
rhetorical convenience, but please don't let this dissuade anyone from
voicing disagreement with any of the claims I've made should they appear
incorrect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20151114/5e0e3b12/attachment-0002.html>