[Web-SIG] PEP 444 (aka Web3)
P.J. Eby
pje at telecommunity.com
Fri Sep 17 17:42:42 CEST 2010
At 03:43 PM 9/17/2010 +0200, And Clover wrote:
>On 09/17/2010 02:03 PM, Armin Ronacher wrote:
>
>>In case we change the spec as Ian mentioned above, I am all for
>>a "wsgi.guessed_encoding" = True flag or something like that.
>
>Yes, I'd like to see that. I believe going with *only* a
>raw-or-reconstructed path_info, rather than having both path_info
>and PATH_INFO, is probably best, for the middleware-dupication
>reasons PJE mentioned.
>
>A more in-depth possibility might be:
>
>wsgi.path_accuracy =
>
> 0: script_name/path_info have been crudely reconstructed from
> SCRIPT_NAME/PATH_INFO from an unknown source. Beware!
> If there is to be backwards compatibility with WSGI1, this
> would be seen as the 'default value' given a missing path_accuracy.
>
> 1: script_name/path_info have been reconstructed, but it is known
> that path_info is accurate, other than %2F and non-ASCII issues.
> That is, it's known that the path doesn't come from IIS's broken
> PATH_INFO, or the IIS error has been detected and compensated for.
>
> 2: script_name/path_info have been reconstructed using known-good
> encodings for the env. The only way in which they may differ from
> the original request path is that a slash might originally have
> been a %2F. (This is good enough for the vast majority of
> applications.)
>
> 3: script_name/path_info come directly from the request path
> without any intervening mangling.
So, do you have an example of what some real-world code is going to
*do* with this information? i.e., what's the use case for knowing
the precise degree of messed-uppedness of the path? ;-)
More information about the Web-SIG
mailing list