> On 5 Jan 2016, at 10:31 PM, Graham Dumpleton <graham.dumple...@gmail.com> > wrote: > >>> For example, mod_wsgi already supports HTTP/2 by virtue of the fact that >>> the mod_h2 module in Apache exists. The existing internal APIs of Apache >>> and how mod_wsgi uses those means that HTTP/2 bridges into the WSGI world >>> with no code changes to mod_wsgi. >> >> Agreed. If all we want is to keep the request/response cycle intact, then >> WSGI supports H2 already. One possibility that has already been suggested >> here would be to define a HTTP/2 extension to WSGI, advertised in the >> environ dict, that allows the application to signal pushes to the server. >> This would be a fairly simple extension to write and implement. > > Sorry to be cynical. Many people have said that changes in the past related > to WSGI will 'be a fairly simple extension to write and implement’. Dig > deeper and it never turns out to be the case. :-) > > Such an extension presumes you actually have a tightly integrated HTTP/2 > server which itself which can maintain a map of resources to push when > getting certain requests and also maintain what may have already been sent > for a session. Even getting to that point is going to be non trivial, even if > an extension may be simple for somehow notifying what the additional > resources to supply should be. > > Right now I would say that with mod_h2 in Apache in would be plain impossible > as it doesn’t I believe even support the idea of pushing resources at this > point. Even then it would most likely be a huge undertaking to get it to work > for mod_wsgi daemon mode as the web application runs in a separate process to > where HTTP/2 is handled. > > If you believe though it is as simple as an extra item in the environ > dictionary, then it can be handled as a separate extension specification per > the URL above.
A side discussion on Twitter has noted that this exists: https://w3c.github.io/preload/ <https://w3c.github.io/preload/> This is already implemented by mod_h2, nghttp2 and H20 at least. This is not my area so I don’t know for sure whether this fits the bill as to what is being described as ‘pushing’. If as I understand it, this allows a WSGI application to return a Link header and mod_h2 in Apache then uses HTTP/2 push to deliver up those resources straight away. If I am misunderstanding this, please let me know. The only problem I do see with this right now if it does what is required, is that in mod_wsgi daemon mode, except for select headers such as Set-Cookie and WWW-Authenticate, response headers of the same name will be joined together. What I don’t know is if mod_h2/nghttp2 will handle where the value of a Link header is joined. It is probably going to be safer if I modify mod_wsgi and add Link to the white list of headers which aren’t joined together. If this does solve the push issue, what is there in HTTP/2 then that one couldn’t do via the existing WSGI interface? Graham
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
