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? ;-)

_______________________________________________
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

Reply via email to