Opened 16 years ago
Last modified 8 years ago
#9435 new Bug
Check out behaviour of wsgi backend with PATH_INFO being an empty string
Reported by: | Malcolm Tredinnick | Owned by: | |
---|---|---|---|
Component: | Core (Other) | Version: | 1.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
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 [8105] 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 (9)
comment:1 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
Yep. This is a bug. The relative redirect case is a problem, for example. Fixing this is going to be a major pain in the butt, I suspect. Fortunately, it's a relative edge-case.
comment:3 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:6 by , 12 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:9 by , 8 years ago
Patch needs improvement: | set |
---|
I want to make sure we at least look at this. It may or may not be an actual issue, since Django's URL resolver doesn't care about the leading '/'; it just treats it as a separator and there must be some kind of "first character" in the URL. So I suspect it's probably not actually causing any misbehaviour and we're just ensuring the
PATH_INFO
equivalent is in a reasonably normalised form. However, we should make sure that the reported information (viarequest.path_info
) matches reality, which may be an empty string, so that means differentiating between our internal normalised version and the upstream passed-in version.