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

[Graham Dumpleton]

> On 6 Jan 2016, at 10:19 PM, Cory Benfield <cory at lukasa.co.uk> wrote:
> 
> 
>> On 6 Jan 2016, at 09:48, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
>> 
>> If this does solve the push issue, what is there in HTTP/2 then that one couldn’t do via the existing WSGI interface?
> 
> Well, plenty, but none that we’d *want* to expose via WSGI with the possible exception of long-running bi-directional communications channels like Websockets, which you’ve already expressed a desire to expose in a different API. =)

Can you elaborate more on the ‘plenty’ part.

This was the issue in the past. People appeared to want access to everything. Thus why the belief you may as well allow them a separate API purpose built for it. Maybe people are becoming more realistic in expectations now as to what they really need for a typical web application as HTTP/2 is better understood.

> Pushing via Link headers is not ideal because it delays the push until after the headers are ready to go, and there’s a tricky ordering concern here (RFC 7540 points out that any PUSH_PROMISE frames should be sent before the response headers and body are sent, which means that we temporarily block the response that is ready to go from WSGI. This is a minor concern, but worth noting.)
> 
> However, I’m happy to say that Pushing via Link headers is the way to go if we’d rather not specify a WSGI-specific API for it.


It appears that Link could at least be a fallback.

The idea of a separate callable to push resources in WSGI environ could still be dealt with as an extension specification and so not need changes to the WSGI specification itself. Worst case is all that callable does is add Link headers to the response. This would likely have to be the case in Apache with mod_h2 as wouldn’t expect handlers to have direct access to an API to do it any other way, plus in mod_wsgi daemon mode is in the wrong process to access any API.

With the possibility that Link header would be a mechanism for use by such a callable, then any calling arguments for the callable should perhaps be modelled on what is possible via the Link header. I could be talking nonsense on that point as I have no idea how server push works in HTTP/2 protocol.

Graham