> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <bchesn...@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 

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.


Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to