> 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. =) 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. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
