Opened 8 years ago

Last modified 3 years ago

#9435 new Bug

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

Reported by: mtredinnick Owned by:
Component: Core (Other) Version: 1.0
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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 "" (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 "" 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 (6)

comment:1 Changed 8 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to mtredinnick
  • Patch needs improvement unset
  • Status changed from new to assigned

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.

comment:2 Changed 8 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to 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 Changed 5 years ago by lukeplant

  • Severity set to Normal
  • Type set to Bug

comment:4 Changed 5 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 5 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:6 Changed 3 years ago by claudep

  • Owner mtredinnick deleted
  • Status changed from assigned to new
Note: See TracTickets for help on using tickets.
Back to Top