Re: WSGI 2.0 Round 2: requirements and call for interest
Graham Dumpleton <[email protected]> Wed, 6 Jan 2016 09:50:21 +1100
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============7957011569747932239== Content-Type: multipart/alternative; boundary="Apple-Mail=_493B33FF-8647-4456-B7AC-966258B75D2E" --Apple-Mail=_493B33FF-8647-4456-B7AC-966258B75D2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Jan 2016, at 9:27 AM, [email protected] wrote: >=20 > On Wed, 6 Jan 2016, Graham Dumpleton wrote: >=20 >>=20 >>> On 6 Jan 2016, at 12:09 AM, [email protected] wrote: >>>=20 >>> As someone who writes their WSGI applications as functions that take >>> `start_response` and `environ` and doesn't bother with much >>> framework the things I would like to see in a minor revision to WSGI >>> are: >>>=20 >>> * A consistent way to access the raw un-decoded request URI. This is >>> so I can reconstruct a realistic `PATH_INFO` that has not been >>> subjected to destructive handling by the server (e.g. apache >>> messing with `%2F`) before continuing on to a route dispatcher. >>=20 >> This is already available in some servers by way of the REQUEST_URI = value. >=20 > Yes, and in others (as mentioned by Benoit) as RAW_URI. One > ("consistent") way would be better. >=20 > [Lots of good information about the challenges associated with using > that information to do anything useful, deleted.] >=20 > What I've done in one app is this: > = https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d908f1a3e58db0= dce7e8d138/tiddlyweb/web/serve.py#L119 >=20 > Despite the fact that that is not strictly correct, it does mostly = work > for the situation described in the comment and the context of that > app. One of the things I want from a light rev of WSGI is not to have > to jump through those hoops. >=20 > It may be that's not feasible but I reckon we're at the wishing > stage of the discussion. Yeah, that code would have problems. One other thing just remembered is that technically it is allowed that = the path part of the request line can actually be a URI. GET http://hostname/a/b/c HTTP/1.0 This would yield: REQUEST_URI: 'http://hostname/a/b/c' <http://hostname/a/b/c'> SCRIPT_NAME: =E2=80=98' PATH_INFO: '/a/b/c=E2=80=99 Obviously I didn=E2=80=99t even mention the % encoding issues as part of = SCRIPT_NAME part as you are obviously aware of those being an issue in = PATH_INFO at least. Lots of fun. Graham= --Apple-Mail=_493B33FF-8647-4456-B7AC-966258B75D2E 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 6 Jan 2016, at 9:27 AM, <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"">On Wed, 6 Jan 2016, Graham Dumpleton wrote:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><br class=3D""><blockquote= type=3D"cite" class=3D"">On 6 Jan 2016, at 12:09 AM, <a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a> = wrote:<br class=3D""><br class=3D"">As someone who writes their WSGI = applications as functions that take<br class=3D"">`start_response` and = `environ` and doesn't bother with much<br class=3D"">framework the = things I would like to see in a minor revision to WSGI<br = class=3D"">are:<br class=3D""><br class=3D"">* A consistent way to = access the raw un-decoded request URI. This is<br class=3D""> so I can = reconstruct a realistic `PATH_INFO` that has not been<br class=3D""> = subjected to destructive handling by the server (e.g. apache<br = class=3D""> messing with `%2F`) before continuing on to a route = dispatcher.<br class=3D""></blockquote><br class=3D"">This is already = available in some servers by way of the REQUEST_URI value.<br = class=3D""></blockquote><br class=3D"">Yes, and in others (as mentioned = by Benoit) as RAW_URI. One<br class=3D"">("consistent") way would be = better.<br class=3D""><br class=3D"">[Lots of good information about the = challenges associated with using<br class=3D"">that information to do = anything useful, deleted.]<br class=3D""><br class=3D"">What I've done = in one app is this:<br class=3D""><a = href=3D"https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d908f1= a3e58db0dce7e8d138/tiddlyweb/web/serve.py#L119" = class=3D"">https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d90= 8f1a3e58db0dce7e8d138/tiddlyweb/web/serve.py#L119</a><br class=3D""><br = class=3D"">Despite the fact that that is not strictly correct, it does = mostly work<br class=3D"">for the situation described in the comment and = the context of that<br class=3D"">app. One of the things I want from a = light rev of WSGI is not to have<br class=3D"">to jump through those = hoops.<br class=3D""><br class=3D"">It may be that's not feasible but I = reckon we're at the wishing<br class=3D"">stage of the discussion.<br = class=3D""></div></div></blockquote></div><br class=3D""><div = class=3D"">Yeah, that code would have problems.</div><div class=3D""><br = class=3D""></div><div class=3D"">One other thing just remembered is that = technically it is allowed that the path part of the request line can = actually be a URI.</div><div class=3D""><br class=3D""></div><div = class=3D""> GET <a href=3D"http://hostname/a/b/c" = class=3D"">http://hostname/a/b/c</a> HTTP/1.0</div><div class=3D""><br = class=3D""></div><div class=3D"">This would yield:</div><div = class=3D""><br class=3D""></div><div class=3D""><div class=3D""> = REQUEST_URI: '<a href=3D"http://hostname/a/b/c'" = class=3D"">http://hostname/a/b/c'</a></div></div><div class=3D""> = SCRIPT_NAME: =E2=80=98'</div><div class=3D""> = PATH_INFO: '/a/b/c=E2=80=99</div><div class=3D""><br class=3D""></div><div= class=3D"">Obviously I didn=E2=80=99t even mention the % encoding = issues as part of SCRIPT_NAME part as you are obviously aware of those = being an issue in PATH_INFO at least.</div><div class=3D""><br = class=3D""></div><div class=3D"">Lots of fun.</div><div class=3D""><br = class=3D""></div><div class=3D"">Graham</div></body></html>= --Apple-Mail=_493B33FF-8647-4456-B7AC-966258B75D2E-- --===============7957011569747932239== 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 --===============7957011569747932239==--