> On 6 Jan 2016, at 20:06, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
>> On 6 Jan 2016, at 10:19 PM, Cory Benfield <c...@lukasa.co.uk> wrote:
>>> On 6 Jan 2016, at 09:48, Graham Dumpleton <graham.dumple...@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 

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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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

Reply via email to