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

Cory Benfield cory at lukasa.co.uk
Wed Jan 6 06:19:38 EST 2016

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

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.


-------------- 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/20160106/8ad88f21/attachment-0001.sig>

More information about the Web-SIG mailing list