Opened 16 years ago

Last modified 8 years ago

#9435 new Bug

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

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

Description

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.

Change History (9)

comment:1 by Malcolm Tredinnick, 16 years ago

Owner: changed from nobody to Malcolm Tredinnick
Status: newassigned

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 by Malcolm Tredinnick, 16 years ago

Triage Stage: UnreviewedAccepted

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 by Luke Plant, 14 years ago

Severity: Normal
Type: Bug

comment:4 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 by Aymeric Augustin, 13 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:6 by Claude Paroz, 12 years ago

Owner: Malcolm Tredinnick removed
Status: assignednew

comment:7 by Tim Graham, 8 years ago

A PR with some discussion of this issue.

comment:8 by Tim Graham, 8 years ago

Has patch: set

comment:9 by Tim Graham, 8 years ago

Patch needs improvement: set
Note: See TracTickets for help on using tickets.
Back to Top