Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Wed, 20 Jan 2016 07:49:13 +1000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============7194371164160983724== Content-Type: multipart/alternative; boundary="Apple-Mail=_D40FAD36-2533-4819-802E-B565FA5D5E0E" --Apple-Mail=_D40FAD36-2533-4819-802E-B565FA5D5E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2016, at 7:43 AM, Benoit Chesneau <[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. 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=E2=80=99t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode = and possibly other implementations. So the =E2=80=98unworkable=E2=80=99 is coming from that you couldn=E2=80=99= t universally implement it across all current WSGI implementations. For = that reason, having it as part of core WSGI is debatable as it would = have to be marked as optional. At that point better as a separate WSGI = extension outside of the WSGI PEP if you did at least want to = standardise such an approach across those WSGI servers that may be able = to support it. Graham --Apple-Mail=_D40FAD36-2533-4819-802E-B565FA5D5E0E 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 7:43 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" 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:0 0 0 .8ex;border-left:1px #ccc = 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 <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>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><br = class=3D""></div><div>So it can=E2=80=99t work for CGI, SCGI, FASTCGI, = mod_wsgi daemon mode and possibly other implementations.</div><div><br = class=3D""></div><div>So the =E2=80=98unworkable=E2=80=99 is coming from = that you couldn=E2=80=99t universally implement it across all current = WSGI implementations. For that reason, having it as part of core WSGI is = debatable as it would have to be marked as optional. At that point = better as a separate WSGI extension outside of the WSGI PEP if you did = at least want to standardise such an approach across those WSGI servers = that may be able to support it.</div><div><br = class=3D""></div><div>Graham</div><br class=3D""></body></html>= --Apple-Mail=_D40FAD36-2533-4819-802E-B565FA5D5E0E-- --===============7194371164160983724== 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 --===============7194371164160983724==--