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

[Graham Dumpleton]

> On 20 Jan 2016, at 8:29 AM, Benoit Chesneau <bchesneau at gmail.com> wrote:
> 
> 
> 
> On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton <graham.dumpleton at gmail.com <mailto:graham.dumpleton at gmail.com>> wrote:
> 
>> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <bchesneau at gmail.com <mailto: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.
> 
> uh? But we don't care about bridging protocols. In WSGI (the gateway), the server accept the socket and anyway pass it to the application via actually a wrapper. Then expect a response from the application.
> 
> Upgrading a socket would simply mean  that the server will forget it (and then consider its job done) once it got an appropriate response from the application. How this is unworkable?

Bridging protocols such as FASTCGI do not provide an ability to upgrade the connection end to end.

That is, yes you could pass the raw socket to the WSGI application when behind FASTCGI, but you are passing it a socket from same process where data being received (and expected to be sent), is using FASTGCI message frames. It is not a raw HTTP socket connection.

There is no way to send a message back to the front end side of the bridged connection where the raw HTTP socket is, to tell the client side of the FASTCGI implementation to stop treating it as a FASTCGI connection to backend process and then suddenly start acting as a raw socket pass through.

Graham

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