[Web-SIG] PEP 444 (aka Web3)
armin.ronacher at active-4.com
Fri Sep 17 14:03:50 CEST 2010
On 9/17/10 11:40 AM, And Clover wrote:
> This is why I am continuing to plead for a 'script_name/path_info are
> authoritative' flag in environ that applications can use to detect
> situations where it is safe to go ahead and rely on them. I want to say
> "Unicode paths are supported if your server/gateway does", not "Unicode
> paths might sometimes work, depending on how you configure your server
> and application".
In case there is no raw value with the current spec, you can see
SCRIPT_NAME and PATH_INFO as unreliable. In case we change the spec as
Ian mentioned above, I am all for a "wsgi.guessed_encoding" = True flag
or something like that.
> It is not just CGI that is affected here! IIS does not provide the
> original undecoded path at all, even through ISAPI.
Unless I am mistaken, the same is true for CGI scripts running on
Apache2 on Windows.
> - on Python 2 on Windows, re-read the environment variables using
> ctypes if available, to avoid the mangling caused by reading
> os.environ using mbcs. (This didn't used to work, as old versions
> of IIS deliberately mbcs-filtered values before putting them in the
> environment, but it does now.)
I did some tests a while ago and was pretty sure that Apache2 on Windows
did the same. Might be wrong though.
> However, the form layer is not really the right place to be doing these
> hacks. It would be better done in the stdlib CGI handler.
The correct place for these hacks would be the appropriate WSGI/Web3
handler of the webserver. Certainly not a particular WSGI/Web3
implementation or even the CGI module of the standard library.
More information about the Web-SIG