On 09/16/2010 02:05 AM, P.J. Eby wrote:
note that the spec's sample CGI
implementation does not itself provide the new variables
It can't: "This is the original URL-encoded value derived from the
request URI. If the server cannot provide this value, it must omit it
from the environ". A CGI gateway doesn't have access to the original
URL-encoded value.
middleware must be explicitly written to handle the case where there is
duplication.
The alternative to duplication would be to allow a gateway to try to
'reconstruct' `path_info` from CGI `PATH_INFO`.
If this is done there really needs to be a flag somewhere to say that it
has been done, ie. that `/` and non-ASCII characters in the path are
unreliable. Otherwise we're just going to end up in the same sorry
situation we have today where all sorts of different encodings and
corruptions lurk inside PATH_INFO and apps simply cannot rely on it.
chr...@plope.com wrote:
> The most sensible thing to me would be to put it in
PATH_INFO.
Please don't have a field with encoded semantics that re-uses the name
of a field that has always had decoded semantics.
--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
_______________________________________________
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
