> On 6 Jan 2016, at 9:27 AM, chris.d...@gmail.com wrote:
> On Wed, 6 Jan 2016, Graham Dumpleton wrote:
>>> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote:
>>> 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
>>> * 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.
>> This is already available in some servers by way of the REQUEST_URI value.
> Yes, and in others (as mentioned by Benoit) as RAW_URI. One
> ("consistent") way would be better.
> [Lots of good information about the challenges associated with using
> that information to do anything useful, deleted.]
> What I've done in one app is this:
> 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.
> 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'>
Obviously I didn’t 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.
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig