Re: Collating follow-up on the future of WSGI

--===============6257108875134881847==
Content-Type: multipart/alternative; boundary=001a113ebb5611ec790529b79059

--001a113ebb5611ec790529b79059
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 19, 2016 at 11:34 PM Graham Dumpleton <
[email protected]> wrote:

>
> On 20 Jan 2016, at 8:29 AM, Benoit Chesneau <[email protected]> wrote:
>
>
>
> On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton <
> [email protected]> wrote:
>
>>
>> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <[email protected]> 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 unworkab=
le.
>>>
>>>
>> 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 socke=
ts
>> 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 WSG=
I
>> application is running. It cannot work where where the WSGI application =
is
>> behind a bridging protocol.
>>
>
>> So it can=E2=80=99t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode an=
d
>> possibly other implementations.
>>
>
> uh? But we don't care about bridging protocols. In WSGI (the gateway), th=
e
> server accept the socket and anyway pass it to the application via actual=
ly
> 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 throu=
gh.
>
>
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

--001a113ebb5611ec790529b79059
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Jan 19, 2016 at 11:34 PM Graham Dumpleton &lt;<a href=3D"mailto:graham.du=
[email protected]">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><blo=
ckquote type=3D"cite"><div>On 20 Jan 2016, at 8:29 AM, Benoit Chesneau &lt;=
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
m</a>&gt; wrote:</div><br><div><div dir=3D"ltr" style=3D"font-family:Helvet=
ica;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px"><br><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton &lt;<a hre=
f=3D"mailto:[email protected]" target=3D"_blank">graham.dumpleton@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><br><div><blockquote type=3D"cite"><div>On 20 Jan 2016, at 7:=
43 AM, Benoit Chesneau &lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>&gt; wrote:</div><br><div><div dir=3D"ltr">=
I will make a more complete answer soon. But about:<br><br><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><br><br>Socket Escape Hatch<br>~~~~~~~~~~~~~~~~=
~~~<br><br>Aside from Benoit, server operators were unanimously dismissive =
of the idea of a socket &#39;escape hatch&#39;. In general it seems like se=
rvers would not be capable of achieving this. I think, therefore, this idea=
 is unworkable.<br><br></blockquote><div><br></div><div>Well it does work. =
This is how websockets works in gunicorn.=C2=A0 Escape is not the right ter=
m anyway. Think it as a socket<span>=C2=A0</span><b>upgrade</b>. And then y=
ou would wonder why it would be unworkable. After all this is how SSL socke=
ts works, so is the protocol negotiation in http2 ...</div><div><br></div><=
div>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.</div></div></div></div></blockquot=
e><br></div></div><div style=3D"word-wrap:break-word"><div>The problem was =
that it would only work in a WSGI server where the original request was acc=
epted on a socket in the same process as the WSGI application is running. I=
t cannot work where where the WSGI application is behind a bridging protoco=
l.=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:b=
reak-word"><div><br></div><div>So it can=E2=80=99t work for CGI, SCGI, FAST=
CGI, mod_wsgi daemon mode and possibly other implementations.</div></div></=
blockquote><div><br></div><div>uh? But we don&#39;t care about bridging pro=
tocols. 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.</div><div><br></div><div>Upgrading a socket would simply m=
ean =C2=A0that the server will forget it (and then consider its job done) o=
nce it got an appropriate response from the application. How this is unwork=
able?</div></div></div></div></blockquote><br></div></div><div style=3D"wor=
d-wrap:break-word"><div>Bridging protocols such as FASTCGI do not provide a=
n ability to upgrade the connection end to end.</div><div><br></div><div>Th=
at is, yes you could pass the raw socket to the WSGI application when behin=
d FASTCGI, but you are passing it a socket from same process where data bei=
ng received (and expected to be sent), is using FASTGCI message frames. It =
is not a raw HTTP socket connection.</div><div><br></div><div>There is no w=
ay to send a message back to the front end side of the bridged connection w=
here the raw HTTP socket is, to tell the client side of the FASTCGI impleme=
ntation to stop treating it as a FASTCGI connection to backend process and =
then suddenly start acting as a raw socket pass through.</div></div><div st=
yle=3D"word-wrap:break-word"><div><br></div></div></blockquote><div><br></d=
iv><div>But how it is related to the WSGI protocol?=C2=A0</div><div><br></d=
iv><div>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.</div><div><br></div><div>Upgrading or escaping in WSGI/Server sense=
 would mean that it would skip the dialog with the application once the app=
lication told it to do.</div><div><br></div><div>For the rest, the applicat=
ion would do what it want on the socket, even giving it to another process/=
thread.</div><div><br></div><div>- benoit</div><div><br></div><div><br></di=
v></div></div>

--001a113ebb5611ec790529b79059--

--===============6257108875134881847==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

--===============6257108875134881847==--