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

[Cory Benfield]

> On 6 Jan 2016, at 20:06, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
> 
> 
>> 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.

Sure. =)

HTTP/2 has the following extra things that a user may want control over:

- Preventing headers being added to the compression context. Good servers will automatically do this for things like Set-Cookie, but an application may have special knowledge about a header being security-relevant. There is no way to signal this in WSGI.
- Forcing certain headers to be added to the compression context. The flip side of the first part is that an application may know that a header is likely to be repeatedly re-used, despite being something that would ordinarily vary, and it may want to pass this knowledge to the server.
- Server push before the complete set of response headers are ready (i.e. before the original response body is rendered).
- Long-running bi-directional communications channels, like Websockets.
- Signaling information about client priority to the application so it can allocate resources effectively.
- Signaling information about flow control to the application so it can allocate resources effectively. (Both of these two could *maybe* be done using generators with WSGI, but it would be imperfect.)
- Controlling flow control windows for large responses (e.g. deliberately shrinking or widening them).
- Controlling flow control widows for connections as a whole.
- Graceful connection shutdown (emitting GOAWAY but continuing to process the outstanding requests/responses).
- Efficient stream cancellation (e.g. sending RST_STREAM for unwanted/invalid requests without tearing down the connection, likely related to the previous point)

HTTP/2 is a very featureful protocol which complex applications could really take advantage of. Worth remembering.


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

Yup, this is definitely an option.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160107/538280a3/attachment.sig>