> Lastly it was noted to me that SCRIPT_NAME and PATH_INFO are > supposed to > be decoded (in the spec it says "The syntax and semantics are > similar to > a decoded HTTP URL 'path' token (defined in RFC 2396 [4])"). I > haven't > been doing this, and the spec isn't clear on this (wsgiref does do > this > decoding, as does Apache). This is to say, when you request > '/foo%20bar/', PATH_INFO should be '/foo bar/'. > > It's also unclear if the WSGI server is expected to normalize the > path, > specifically things like /foo/../bar -- Apache does do this, wsgiref > does not. (Is posixpath.normpath good enough to do that?)
I've been meaning to bring this up. I wrote a proxy using WSGI and recently moved to using the cherrypy wsgi server rather than the one in wsgiref. In wsgiref PATH_INFO is always the full path supplied by the client, if the client makes a proxy request and gives the entire uri as the path wsgiref doesn't chop it down to _just_ the destination path without scheme/host/port/etc (although it does remove the query string), while cherrypy does. Looking at the spec it would seem cherrypy is correct and this may be a bug in wsgiref. Using the code sample in PEP 333 I was able to reconstruct the dest url in both cases. -Mikeal _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
