> 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