<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 12 Nov 2015 at 12:46 Cory Benfield <<a href="mailto:cory@lukasa.co.uk">cory@lukasa.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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).</div></div></blockquote><br></div><div class="gmail_quote">I'd like to point out a few things on this topic:<br><br></div><div class="gmail_quote">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.<br><br></div><div class="gmail_quote">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".<br><br></div><div class="gmail_quote">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.<br><br></div><div class="gmail_quote">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.<br><br>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.<br><br></div><div class="gmail_quote">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).<br><br></div><div class="gmail_quote">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.<br><br></div><div class="gmail_quote">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.<br></div></div>