home / django_tickets / tickets

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
Powered by Datasette · Queries took 1.654ms