> On 4 Jan 2016, at 14:56, Damjan Georgievski <gdam...@gmail.com> 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
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
