[Web-SIG] Future of WSGI
and-py at doxdesk.com
Thu Nov 26 14:06:32 CET 2009
Ian Bicking wrote:
> The proposal that seemed to work best was to keep the environ as str (i.e.,
> 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.
This could be achieved by giving the new variables a different name and
only including them if they're safe (leaving the application to fall
back to the old variables where unavailable), or by having a flag to
specify they're verbatim and leaving it unset when unmangled verbatim is
> Also I think everyone is okay with removing start_response.
+0.5: very much happy to see it gone, but if it causes any more delay to
a WSGI update I'm also not unhappy if it stays. My primary concern is
that a Python-3-compatible WSGI is available as soon as possible; every
long argument in here seems to lead to no resolution. I want to release
Python 3 web code, and cannot whilst WSGI remains in flux.
Whilst in principle I kind of agree with Malthe that keeping the
CGI-derived environ separate from items like wsgi.input would be
appropriate, in practice I don't give a stuff about it: the merged
dictionary causes no practical problems, and changing it would be an
enormous upheaval for all WSGI users.
WSGI doesn't need to be pretty, it needs to be widely-compatible.
Authors who want pretty can use frameworks, which will be happy to
deliver elegant Request and Response objects.
mailto:and at doxdesk.com
More information about the Web-SIG