[Web-SIG] Collating follow-up on the future of WSGI

[Graham Dumpleton]

> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <bchesneau at gmail.com> wrote:
> 
> I will make a more complete answer soon. But about:
> 
> 
> 
> Socket Escape Hatch
> ~~~~~~~~~~~~~~~~~~~
> 
> Aside from Benoit, server operators were unanimously dismissive of the idea of a socket 'escape hatch'. In general it seems like servers would not be capable of achieving this. I think, therefore, this idea is unworkable.
> 
> 
> Well it does work. This is how websockets works in gunicorn.  Escape is not the right term anyway. Think it as a socket upgrade. And then you would wonder why it would be unworkable. After all this is how SSL sockets works, so is the protocol negotiation in http2 ...
> 
> There is nothing magic there until you try to over engineer the stuff. Upgrading a sockets means that you tell to the server to forget it. This is how most concurrent servers work today.

The problem was that it would only work in a WSGI server where the original request was accepted on a socket in the same process as the WSGI application is running. It cannot work where where the WSGI application is behind a bridging protocol.

So it can’t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode and possibly other implementations.

So the ‘unworkable’ is coming from that you couldn’t universally implement it across all current WSGI implementations. For that reason, having it as part of core WSGI is debatable as it would have to be marked as optional. At that point better as a separate WSGI extension outside of the WSGI PEP if you did at least want to standardise such an approach across those WSGI servers that may be able to support it.

Graham

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160120/a4cfff7e/attachment.html>