[Web-SIG] Future of WSGI

[And Clover]

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 
unavailable.

> 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.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/