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

[Benoit Chesneau]

On Tue, Jan 19, 2016 at 11:34 PM Graham Dumpleton <
graham.dumpleton at gmail.com> wrote:

>
> 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> wrote:
>
>>
>> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <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.
>
>
But how it is related to the WSGI protocol?

It is expected that the wsgi server accept on a socket (directly or behind
a proxy) and provide enough to the application so they can read and write.

Upgrading or escaping in WSGI/Server sense would mean that it would skip
the dialog with the application once the application told it to do.

For the rest, the application would do what it want on the socket, even
giving it to another process/thread.

- benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160119/461614eb/attachment.html>