Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Wed, 20 Jan 2016 16:21:45 +1000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============2039959846277680641== Content-Type: multipart/alternative; boundary="Apple-Mail=_C0704470-6EE7-4DB0-A599-A8090AB6D3C4" --Apple-Mail=_C0704470-6EE7-4DB0-A599-A8090AB6D3C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Jan 2016, at 8:56 AM, Robert Collins <[email protected]> = wrote: >=20 >> REQUEST_URI environ variable >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>=20 >> Multiple contributors expressed an interest in bringing this = environment variable into WSGI directly, making it a required part of = the environ dictionary. An alternative name for this was RAW_URI. >=20 > If its reasonable available to e.g. Apache modules, I could see doing > this. That said, why have two? Why not require that URI be the 'RAW' > URI? I don't see the benefit in having two separate variables. The history on this one was that Apache and anything that copied what = Apache did always provided this as REQUEST_URI. It has some de-facto = standing therefore as meant it was also always present in many CGI, = SCGI, FASTCGI environments as a result. When Gunicorn decided to add the equivalent, they chose not to use what = Apache has always used and chose a different name. It isn=E2=80=99t an issue therefore of allowing both, it makes more = sense only to note use of REQUEST_URI as it has longer standing. If = adopted, Gunicorn would need to use REQUEST_URI, but only Gunicorn would = have to continue to use RAW_URI to support people who wrote WSGI = applications which were only looking for what Gunicorn used and didn=E2=80= =99t know there was another convention for it. As to the comment: Why not require that URI be the =E2=80=98RAW=E2=80=99 URI? am not sure what you =E2=80=98UR=E2=80=99 you are talking about, if you = are talking about some other existing variables in the WSGI = specification. Graham= --Apple-Mail=_C0704470-6EE7-4DB0-A599-A8090AB6D3C4 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:56 AM, Robert Collins <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D""><blockquote type=3D"cite" 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"">REQUEST_URI environ variable<br = class=3D"">~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br class=3D""><br = class=3D"">Multiple contributors expressed an interest in bringing this = environment variable into WSGI directly, making it a required part of = the environ dictionary. An alternative name for this was RAW_URI.<br = class=3D""></blockquote><br 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""><span = 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; float: none; display: inline = !important;" class=3D"">If its reasonable available to e.g. Apache = modules, I could see doing</span><br 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""><span= 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; float: none; display: inline = !important;" class=3D"">this. That said, why have two? Why not require = that URI be the 'RAW'</span><br 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""><span= 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; float: none; display: inline = !important;" class=3D"">URI? I don't see the benefit in having two = separate variables.</span></div></div></blockquote></div><br = class=3D""><div class=3D"">The history on this one was that Apache and = anything that copied what Apache did always provided this as = REQUEST_URI. It has some de-facto standing therefore as meant it was = also always present in many CGI, SCGI, FASTCGI environments as a = result.</div><div class=3D""><br class=3D""></div><div class=3D"">When = Gunicorn decided to add the equivalent, they chose not to use what = Apache has always used and chose a different name.</div><div = class=3D""><br class=3D""></div><div class=3D"">It isn=E2=80=99t an = issue therefore of allowing both, it makes more sense only to note use = of REQUEST_URI as it has longer standing. If adopted, Gunicorn would = need to use REQUEST_URI, but only Gunicorn would have to continue to use = RAW_URI to support people who wrote WSGI applications which were only = looking for what Gunicorn used and didn=E2=80=99t know there was another = convention for it.</div><div class=3D""><br class=3D""></div><div = class=3D"">As to the comment:</div><div class=3D""><br = class=3D""></div><div class=3D""> Why not require that URI = be the =E2=80=98RAW=E2=80=99 URI?</div><div class=3D""><br = class=3D""></div><div class=3D"">am not sure what you =E2=80=98UR=E2=80=99= you are talking about, if you are talking about some other existing = variables in the WSGI specification.</div><div class=3D""><br = class=3D""></div><div class=3D"">Graham</div></body></html>= --Apple-Mail=_C0704470-6EE7-4DB0-A599-A8090AB6D3C4-- --===============2039959846277680641== 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 --===============2039959846277680641==--