Re: WSGI 2.0 Round 2: requirements and call for interest

Cory Benfield <[email protected]> Mon, 4 Jan 2016 15:15:40 +0000

Newsgroups	gmane.comp.python.web
Message-ID	<[email protected]>

> On 4 Jan 2016, at 14:56, Damjan Georgievski <[email protected]> wrote:
> 
>>>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?**
>>> …
>>>> - Support websockets
>>>> - Support HTTP/2
>>> 
>>> What does HTTP/2 support mean? What features of HTTP/2 need to be
>>> exposed in the wsgi api?
>> 
>> (CC-ing the list)
>> 
>> The current WSGI API does not provide any consensus method for doing server push. Such a thing could absolutely be done as an extension to WSGI in its current form, and we should consider that.
>> 
>> More generally, HTTP/2 is a bit more generous with what can be done with a stream than is the case in HTTP/1.1. For example, a stream could in principle be kept open indefinitely and used as a bi-directional communications channel: WSGI in its current form does not make that easy to do.
>> 
> 
> So will a general solution for both HTTP/2 and Websockets be exposing
> the underlaying socket as an 'wsgi.fd' environment variable?

I don’t believe that will work.

Both HTTP/2 and Websockets have framing logic, and HTTP/2 also has a moderately-complex connection-level state machine that makes passing off the FD to an application a fraught endeavour. I suspect in both cases they will be best handled by having a extension protocol that allows the protocol-specific logic to function sensibly. In both cases, standard Python generators used as coroutines would be totally suitable, with concurrency being the only fly in the ointment to getting this right.

Cory

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

signature.asc (application/pgp-signature, 801 B)