[Web-SIG] PEP 444 (aka Web3)
Ian Bicking
ianb at colorstudy.com
Fri Sep 17 19:02:52 CEST 2010
On Fri, Sep 17, 2010 at 9:43 AM, And Clover <and-py at doxdesk.com> 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.
path_accuracy is certainly a better name than encoding; nothing here
actually relates to encoding (except insofar as attempts to encode or
reencode values corrupts the path). Personally I wouldn't want to split it
up this much, I'd rather a simple flag to indicate something was guessed,
vs. an accurate request. The only real value I see in it is to help people
debug problems. Maybe. I'm not sure it's that realistic to imagine this
will be noticed by people deploying software and encountering problems. A
helpful application could use it to warn the deployer of potential problems.
It seems that it would be possible to create a WSGI application and client
library that together can detect and help resolve these issues. E.g., the
application always returns the values of script_name, path_info, and
query_string, and the client fires off a bunch of different requests to see
how it gets interpreted. It could suggest corrections until everything
passes.
I would really like to see concerns over bad gateways not be used to keep
valuable information out of the spec. We want people to use well-configured
gateways that accurately represent requests. There are limits, e.g., in
environments where information is lost. The only really problematic example
is losing the distinction between %2f and /, and I think it's reasonable to
suggest that applications should avoid making that distinction in the path
if they want to be easily deployed in different environments.
--
Ian Bicking | http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100917/1a41f7b5/attachment.html>
More information about the Web-SIG
mailing list