Opened 6 years ago

Closed 6 years ago

#19594 closed Bug (invalid)

urlpatterns not respected for trailling slashed when mod_rewrite is on

Reported by: francisl Owned by: nobody
Component: Core (Other) Version: 1.3
Severity: Normal Keywords: mod_rewrite urlpatterns
Cc: DevEquipeWeb@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


'django.core.handlers.base.get_script_name' behaves strangely when extra slashes are added at the end of a URL and FORCE_SCRIPT_NAME is not set.

The returned value will repeat the URL if extra slashes is added.
This will lead to a 404
If there is a regex explicitly accepting extra slashes, it will be ignored
This condition is not the expected behavior, but there is also no reason to return an erroneous response and to prevent the resolver to do its work

e.g. :

Requested /api/news?key=value

Requested /api/news/?key=value
Returns /a/api/news

The "/a" is the URL starting to repeat itself.

How to reproduce:
Run django with wsgi, apache and mod_rewrite on
Request urls with extra ending slashes

Set FORCE_SCRIPT_NAME = "" in the settings.
Since FORCE_SCRIPT_NAME isn't defaulted, it can lead to confusion and make this strange behavior hard to debug.

Don’t add the SCRIPT_URL to the PATH_INFO if FORCE_SCRIPT_NAME is not set. See patch.txt

This also affect django to 1.5

Attachments (1)

get_script_name.patch (572 bytes) - added by francisl 6 years ago.
django.core.handles.base.get_script_name correct unexpected condition when extra slashes at the end of the url

Download all attachments as: .zip

Change History (4)

Changed 6 years ago by francisl

Attachment: get_script_name.patch added

django.core.handles.base.get_script_name correct unexpected condition when extra slashes at the end of the url

comment:1 Changed 6 years ago by anonymous

Version: 1.21.3

comment:2 Changed 6 years ago by Florian Apolloner

Sry we won't fix that in 1.3, is this still an issue in the yet to be release 1.5 version? Also could you share your rewrite rules with us?

comment:3 Changed 6 years ago by Carl Meyer

Resolution: invalid
Status: newclosed

The description says "affects Django to 1.5", but looking at the get_script_name function in 1.5 the description of the problem and the suggested patch make no sense. If FORCE_SCRIPT_NAME is not None, the entire function is short-circuited and the value of FORCE_SCRIPT_NAME is returned immediately. So adding an and FORCE_SCRIPT_NAME is not None later in the function is a no-op.

It may be that this patch made some sense in Django 1.3 (I haven't checked), but that's not relevant, since this wouldn't qualify for backport to 1.3 (or 1.4) anyway.

So closing as invalid.

Note: See TracTickets for help on using tickets.
Back to Top