Hi,
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.
Regards,
Armin
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
