urlpatterns not respected for trailling slashed when mod_rewrite is on

[francisl]

'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
Returns api/news/

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

Workaround:
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.

Solution:
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

[francisl]

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

[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?

[Carl Meyer]

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.