tickets: 9435
This data as json
| id | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 9435 | 2008-10-24 03:43:35 | 2016-12-29 19:14:22 | 2022-03-06 03:44:53.363647 | Accepted | new | Core (Other) | Bug | Normal | 1.0 | Check out behaviour of wsgi backend with PATH_INFO being an empty string | 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. | mtredinnick | 0 | 1 | 1 | 0 | 0 | 0 |