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

[Benoit Chesneau]

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?

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