Check out behaviour of wsgi backend with PATH_INFO being an empty string

[Malcolm Tredinnick]

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.

[Malcolm Tredinnick]

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 (via request.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.

[Malcolm Tredinnick]

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.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Tim Graham]

A ​PR with some discussion of this issue.

[Tim Graham]

​PR

[Andreu Vallbona]

I think I can work on this ticket. I've created a draft pull request ​​PR Let me know what do you think about it.

[Jacob Walls]

Spoke with Andreu at Django on the Med 🏖️. There is a failing test, but the PR is in more of a request for comment state, to raise the question of whether to proceed at all or wontfix.

[Jacob Walls]

Had a chance to catch up with the ticket discussion. Sounds like there hasn't been any new information suggesting a wontfix. I'd be happy to look at the changes in more detail once the tests are passing, as the implementation might need to change a bit.