URL dispatcher including forward slashes in parameter capture

[Matthew Riedel]

Given the following URL object:

url(r'^password/(?P<username>\S+)/$', views.reset_password, name='password'),

and the following URL:

password/myusername/favicon.ico/

Django seems to be capturing username as myusername/favicon.ico instead of myusername.

When tested in Python's CLI, the parameter capture works properly:

>>> url = re.compile(r'^password/(?P<username>\S+)/', re.U)
>>> match = url.match('password/myusername/favicon.ico')
>>> match.group('username')
'myusername'
>>> url = re.compile(r'^password/(?P<username>\S+)/', re.L)
>>> match = url.match('password/myusername/favicon.ico')
>>> match.group('username')
'myusername'

I would expect if the regexp was the issue, I would see mysuername/favicon.ico in the Python output, also.

I'm using Python 2.7.5 on RHEL 7 with a Virtual Environment for Django 1.8.8. This also happens in 1.8.7. No changes were made to this application's url.py file since July, and this issue only popped up since updating to Django 1.8.7 from an earlier version of Django 1.8 (not sure which minor version).

For now, I'm using a \w+ regular expression instead of a \S+ - but that's only a temporary fix. Sometimes I do need to match on special characters other than underscore (e.g., dash, plus sign, etc.)

[Marten Kenbeek]

In your URLconf you use the end-of-line character $, so the slash must be the last character of the url. Since the original url password/myusername/favicon.ico does not match, you are redirected to the same url with a trailing slash. The capturing group then must be anything between password/ and the last /.

In your CLI example, you omit the $, so the / does not have to be the last character, and the regex matches the original url. The capturing group then matches everything up to the last /, which is just myusername in this case.

If you need to match more than just \w, you can define a more inclusive character set, i.e.:

url(r'^password/(?P<username>[\w+-]+)/$', views.reset_password, name='password'),

I don't see any of the relevant code that has changed in 1.8.x releases, so I suspect that's the whole of the issue. If there is something else that points at a regression in a 1.8.x. release, please reopen.