#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 , 5 years ago
comment:2 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Escaped newlines are legitimate in URLs (and required in cases, e.g. #24962).
comment:3 by , 5 years ago
In that case, isn't the path
converter incorrect in not accepting newlines?
comment:4 by , 5 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 , 3 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.