Re: Collating follow-up on the future of WSGI
Benoit Chesneau <[email protected]> Tue, 19 Jan 2016 22:29:04 +0000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <CAJNb-9qJo6M1Hsxfuo3Jc9R_RhDYvHHNm2XnDbRexd_TDxc18g@mail.gmail.com> |
--===============3700922529986710121== Content-Type: multipart/alternative; boundary=001a113f16da39834d0529b7666d --001a113f16da39834d0529b7666d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 unworkabl= e. >> >> > 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 socket= s > 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 i= s > behind a bridging protocol. > > So it can=E2=80=99t 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 --001a113f16da39834d0529b7666d 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 10:49 PM Graham Dumpleton <<a href=3D"mailto:graham.du= [email protected]">[email protected]</a>> 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 7:43 AM, Benoit Chesneau <= <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a>> wrote:</div><br><div><div dir=3D"ltr">I will make a more complete= answer soon. But about:<br><br><div class=3D"gmail_quote"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"><br><br> Socket Escape Hatch<br> ~~~~~~~~~~~~~~~~~~~<br> <br> 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 unworka= ble.<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 term anyway. T= hink it as a socket <b>upgrade</b>. 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 ...</div><div><br></div><div>There is nothing magic th= ere until you try to over engineer the stuff. Upgrading a sockets means tha= t you tell to the server to forget it. This is how most concurrent servers = work today.</div></div></div></div></blockquote><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 accepted on a socket in the sam= e process as the WSGI application is running. It cannot work where where th= e WSGI application is behind a bridging protocol.=C2=A0</div></div></blockq= uote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><di= v><br></div><div>So it can=E2=80=99t work for CGI, SCGI, FASTCGI, mod_wsgi = daemon mode and possibly other implementations.</div></div></blockquote><di= v><br></div><div>uh? But we don't care about bridging protocols. In WSG= I (the gateway), the server accept the socket and anyway pass it to the app= lication via actually a wrapper. Then expect a response from the applicatio= n.</div><div><br></div><div>Upgrading a socket would simply mean =C2=A0that= the server will forget it (and then consider its job done) once it got an = appropriate response from the application. How this is unworkable?</div><di= v><br></div><div>- benoit</div></div></div> --001a113f16da39834d0529b7666d-- --===============3700922529986710121== 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 --===============3700922529986710121==--