Opened 4 years ago
Closed 4 years ago
#31858 closed Bug (fixed)
space outside of parameters are not allowed in path() routes
Reported by: | Kevin Michel | Owned by: | Tim Park |
---|---|---|---|
Component: | Core (URLs) | Version: | 3.1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
To avoid ambiguities in parameter names, space were forbidden from path routes in #29667 .
However, the fix in https://github.com/django/django/pull/11688 forbids space anywhere,
including outside of <> parameters.
Urls with spaces are weird and subject to url encoding in the browser bar, but they appear
occasionally, I hit the bug with a real url after migrating to 3.1.
re_path allows matching those urls as a workaround but it's weird to have to use re just
because of a space in an otherwise simple route.
If the bug is deemed valid, I can work on a patch to only forbid spaces between < and > parts.
Change History (6)
comment:1 by , 4 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 4 years ago
Hi,
I agree that spaces in URLs are unsafe, and we should urlencode them
when transmitting or writing URLs, like the browser does automatically.
However, URLs are urldecoded before reaching the router (which is the
right thing to do as far as I understand it), the router matches a decoded
path, which is not really an URL anymore.
In the WSGI case, the url decoding is done when filling environ['PATH_INFO']
,
for instance here: https://github.com/python/cpython/blob/master/Lib/wsgiref/simple_server.py#L85
Because of that, it's not possible to try to match the safe "%20" in a route
as if it was an URL.
I think spaces in URLs are indeed unsafe and invalid but spaces in the
path for the router are safe and should be allowed.
Not being able to match all valid paths with a route is a possibility but it's
a bit surprising.
comment:3 by , 4 years ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
comment:4 by , 4 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Hey guys, PR opened here: https://github.com/django/django/pull/13364
Let me know your thoughts!
comment:5 by , 4 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Hi Kevin. Thanks for the report, but I don't think we should support this.
RFC 1738 is pretty clear on this:
and:
(Search for the "unsafe" section header.)
I think "If you want to do this nonetheless then use
re_path
" is more than reasonable.