[Web-SIG] Future of WSGI
graham.dumpleton at gmail.com
Thu Nov 26 22:59:50 CET 2009
2009/11/27 And Clover <and-py at doxdesk.com>:
> Ian Bicking wrote:
>> The proposal that seemed to work best was to keep the environ as str
>> unicode in Python 3), and eliminate the problematic SCRIPT_NAME and
>> PATH_INFO, replacing them with url-encoded values.
> Ah, OK, if that's where we got to I'm happy with that - as long as the
> application/framework can tell the difference between (a) old-school WSGI
> 1.0 decoded PATH_INFO, (b) new verbatim PATH_INFO, and (c) a new verbatim
> PATH_INFO that has been created from an old PATH_INFO by a WSGI handler
> unfortunate enough to be running under CGI or IIS, potentially including
> mangled characters. I would prefer to avoid the latter completely.
I was determined to stay out of this conversation, as don't
particularly care anymore, but want to set the record straight.
What Ian was describing was just one of a few proposals which were put
up about additional changes to WSGI on top of what is already the
defacto WSGI 1.X definition for Python 3.X as defined by existing
practice in the form of wsgiref in Python 3.1 and mod_wsgi 3.0 (as
implemented for more than a year, and recently released officially due
to being fed up with waiting). One of the other major WSGI servers
also is implementing that defacto WSGI 1.X definition for Python 3.X.
That WSGI server hasn't as far as I know been officially released, so
will leave it up to author to comment on whether they are still
intending it to release it that way.
Anyway, Ian's proposal just so happened to be the last one which was
discussed. Just like the other proposals there were issues with it and
not everyone necessarily agreed. Note that lack of response doesn't
mean consent, and frankly various people were quite tired of the
discussion at that point and various people whose opinions would be
important to know had dropped out of the discussion.
I would be even further disappointed in Python WEB-SIG if that last
proposal now simply got rubber stamped purely because it was the last
proposal anyone remembered, without some critical study done on
whether it is even practical to implement in a reliable way across
hosting mechanisms which don't have direct access to the actual
processing of request headers and in particular the decoding of the
original REQUEST_URI into SCRIPT_NAME and PATH_INFO. Specifically, in
relation to the inability or potential difficulty in such hosting
mechanisms to extract out from REQUEST_URI the original parts which
mapped to the final SCRIPT_NAME and PATH_INFO.
No matter what you all end up deciding to do, and whether or not
start_response() is dropped, any new specification will have to be
called WSGI 2.0 due to the existence of the defacto WSGI 1.X
definition for Python 3.X.
More information about the Web-SIG