id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
9435	Check out behaviour of wsgi backend with PATH_INFO being an empty string	Malcolm Tredinnick	Andreu Vallbona	"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.
"	Bug	assigned	Core (Other)	1.0	Normal				Accepted	1	0	0	1	0	0