Check out behaviour of wsgi backend with PATH_INFO being an empty string
|Reported by:||Malcolm Tredinnick||Owned by:|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Transferring a side-issue from #3414 (comment 23 over there):
Note: the WSGI spec allows PATH_INFO to be empty or missing; specifically:
"This may be an empty string, if the request URL targets the application root and does NOT have a trailing slash." (emph. added)
And WSGI servers are allowed to omit PATH_INFO (and various other variables) if they are an empty string.
IIUC, this means that  doesn't correctly handle the case where someone goes to "foo.com/django" (no trailing '/'), because it wrongly assumes that a missing PATH_INFO is a '/'. Per the WSGI spec, a missing PATH_INFO is in fact an empty string. That means that relative URLs at the root of a Django site would not work correctly under servers that omit an empty PATH_INFO.
Whether the OP issue here is a configuration problem is irrelevant to this piece: it is perfectly legal for a WSGI server to omit PATH_INFO if it's an empty string, and its omission means that it's an EMPTY string, not a '/'.
Conversely, if a WSGI server is ommitting PATH_INFO when PATH_INFO should be a "/" (i.e. the URL was "foo.com/django/" with a trailing "/"), then that server is seriously broken and should be fixed. (But I'm not seeing anything here that suggests this is actually the case.)
Either way, however, the code that's defaulting a missing PATH_INFO to "/" appears to be quite wrong: either creating a bug or masking one somewhere else.
Change History (7)
comment:1 Changed 8 years ago by
|Owner:||changed from nobody to Malcolm Tredinnick|
|Patch needs improvement:||unset|
|Status:||new → assigned|