> 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?


Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to