[Web-SIG] PEP 444 (aka Web3)

[Armin Ronacher]

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