On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton < graham.dumple...@gmail.com> wrote:
> > 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 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? - benoit
_______________________________________________ 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
