> On 20 Jan 2016, at 8:56 AM, Robert Collins <robe...@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.

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to