[Web-SIG] Collating follow-up on the future of WSGI

Graham Dumpleton graham.dumpleton at gmail.com
Wed Jan 20 01:21:45 EST 2016

> On 20 Jan 2016, at 8:56 AM, Robert Collins <robertc at robertcollins.net> wrote:
>> REQUEST_URI environ variable
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 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.
> 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’t 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’t know there was another convention for it.

As to the comment:

    Why not require that URI be the ‘RAW’ URI?

am not sure what you ‘UR’ you are talking about, if you are talking about some other existing variables in the WSGI specification.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160120/0d116bf9/attachment.html>

More information about the Web-SIG mailing list