On Thu, 12 Nov 2015 at 12:46 Cory Benfield <c...@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.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
