> 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

Reply via email to