[Web-SIG] WSGI & CGI spec

[Mikeal Rogers]

> 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