Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Wed, 20 Jan 2016 08:34:12 +1000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============6386468929944831307== Content-Type: multipart/alternative; boundary="Apple-Mail=_6D7D4F7F-94F3-416D-A6DF-671F83137E27" --Apple-Mail=_6D7D4F7F-94F3-416D-A6DF-671F83137E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2016, at 8:29 AM, Benoit Chesneau <[email protected]> = wrote: >=20 >=20 >=20 > On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton = <[email protected] <mailto:[email protected]>> wrote: >=20 >> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <[email protected] = <mailto:[email protected]>> wrote: >>=20 >> I will make a more complete answer soon. But about: >>=20 >>=20 >>=20 >> Socket Escape Hatch >> ~~~~~~~~~~~~~~~~~~~ >>=20 >> 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. >>=20 >>=20 >> 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 ... >>=20 >> 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. >=20 > 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.=20 >=20 > So it can=E2=80=99t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode = and possibly other implementations. >=20 > 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. >=20 > 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 --Apple-Mail=_6D7D4F7F-94F3-416D-A6DF-671F83137E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 20 Jan 2016, at 8:29 AM, Benoit Chesneau <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 16px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = class=3D""><br class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"">On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br = class=3D""></div><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-style: solid; padding-left: 1ex;"><div = style=3D"word-wrap: break-word;" class=3D""><br class=3D""><div = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 20 = Jan 2016, at 7:43 AM, Benoit Chesneau <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> wrote:</div><br class=3D""><div = class=3D""><div dir=3D"ltr" class=3D"">I will make a more complete = answer soon. But about:<br class=3D""><br class=3D""><div = class=3D"gmail_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-style: solid; padding-left: 1ex;"><br = class=3D""><br class=3D"">Socket Escape Hatch<br = class=3D"">~~~~~~~~~~~~~~~~~~~<br class=3D""><br class=3D"">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.<br class=3D""><br class=3D""></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">Well it does work. This is how = websockets works in gunicorn. Escape is not the right term anyway. = Think it as a socket<span class=3D"Apple-converted-space"> </span><b = class=3D"">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 class=3D""><br class=3D""></div><div = class=3D"">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></blockquote><br class=3D""></div></div><div= style=3D"word-wrap: break-word;" class=3D""><div class=3D"">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. </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, 204, 204); = border-left-style: solid; padding-left: 1ex;"><div style=3D"word-wrap: = break-word;" class=3D""><div class=3D""><br class=3D""></div><div = class=3D"">So it can=E2=80=99t work for CGI, SCGI, FASTCGI, mod_wsgi = daemon mode and possibly other = implementations.</div></div></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">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.</div><div class=3D""><br = class=3D""></div><div class=3D"">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?</div></div></div></div></blockquote><br = class=3D""></div><div>Bridging protocols such as FASTCGI do not provide = an ability to upgrade the connection end to end.</div><div><br = class=3D""></div><div>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.</div><div><br class=3D""></div><div>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.</div><div><br class=3D""></div><div>Graham</div><br = class=3D""></body></html>= --Apple-Mail=_6D7D4F7F-94F3-416D-A6DF-671F83137E27-- --===============6386468929944831307== 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 --===============6386468929944831307==--