#30530 closed Bug (fixed)
url `path` accepts newlines in various places.
| Reported by: | Sjoerd Job Postmus | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (URLs) | Version: | dev |
| 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 |
Description
Consider the following simplified urls.py.
from django.http import HttpResponse
from django.urls import path
def path_view(request):
return HttpResponse('<pre>===>' + request.path + '<===</pre>')
def render_something(request, something):
return HttpResponse('<pre>===>' + something + '<===</pre>')
urlpatterns = [
path('hello/', path_view),
path('foo/<something>/bar/', render_something),
]
By accessing http://localhost:8000/hello/%0a, it's clear that the newline is accepted in the URL. This is because the underlying logic uses a $ in the regular expression, instead of \Z..
By accessing http://localhost:8000/foo/hello%0aworld/bar/, it's clear that the default str converter accepts anywhere in the segment. This is because it uses a negative match [^/]+, which happily accepts a newline character (both %0a and %0d).
I propose changing the $ to \Z, and the negative match to [^/\r\n]+.
I would also suggest changing the documentation on the re_path to suggest \Z instead of $, though that may be more controversial.
Change History (15)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Escaped newlines are legitimate in URLs (and required in cases, e.g. #24962).
comment:3 by , 6 years ago
In that case, isn't the path converter incorrect in not accepting newlines?
comment:4 by , 6 years ago
The converters are as they are as a result of design decisions made when introducing the feature. Anyone needing different can implement custom converters.
comment:10 by , 4 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
Thanks for this report, however is there any reason to add this restriction? I don't see any issue in accepting encoded newline characters in URL parameters. Moreover this behavior is documented and can be used by users.