[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Graham Dumpleton]

> On 5 Jan 2016, at 10:31 PM, Graham Dumpleton <graham.dumpleton at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160106/2bca6e59/attachment.html>