> On 20 Jan 2016, at 8:29 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: > > > > On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton <graham.dumple...@gmail.com > <mailto:graham.dumple...@gmail.com>> wrote: > >> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <bchesn...@gmail.com >> <mailto: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 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
_______________________________________________ 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