[Django] #32710: static template tag converts '?' to '%3F'
Django
-------------------------------------+-------------------------------------
Reporter: Adrian | Owner: nobody
Garcia |
Type: Bug | Status: new
Component: Template | Version: 3.1
system |
Severity: Normal | Keywords: static template
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
As the title suggests, the static template tag converts all question marks
to '%3F' which still seems to work, but I don't think this is intended.
Template code:
{{{
<script src="{% static
'bootstrap/js/bootstrap.bundle.min.js?test'%}"></script>
}}}
Output is:
{{{
<script src="/js/bootstrap.bundle.min.js%3Ftest"></script>
}}}
I followed the execution path and the replacement happens in
{{{django.utils.encoding.filepath_to_uri}}} when {{{urllib.parse.quote}}}
is called. I think '?' should be denoted as a safe character because
otherwise, the function will replace it with a byte representation
--
Ticket URL: <https://code.djangoproject.com/ticket/32710>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Adrian Garcia | Owner: nobody
Type: Bug | Status: new
Component: Template system | Version: 3.1
Severity: Normal | Resolution:
Keywords: static template | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Adrian Garcia):
[https://github.com/django/django/pull/14340 Proposed patch]
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:1>
Django
Reporter: Adrian Garcia | Owner: nobody
Component: Template system | Version: 3.1
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Description changed by Adrian Garcia:
Old description:
> As the title suggests, the static template tag converts all question
> marks to '%3F' which still seems to work, but I don't think this is
> intended.
>
> Template code:
> {{{
> <script src="{% static
> 'bootstrap/js/bootstrap.bundle.min.js?test'%}"></script>
> }}}
>
> Output is:
> {{{
> <script src="/js/bootstrap.bundle.min.js%3Ftest"></script>
> }}}
>
> I followed the execution path and the replacement happens in
> {{{django.utils.encoding.filepath_to_uri}}} when {{{urllib.parse.quote}}}
> is called. I think '?' should be denoted as a safe character because
> otherwise, the function will replace it with a byte representation
New description:
As the title suggests, the static template tag converts all question marks
to '%3F' which will cause CSS and JS to fail to load.
Template code:
{{{
<script src="{% static
'bootstrap/js/bootstrap.bundle.min.js?test'%}"></script>
}}}
Output is:
{{{
<script src="/js/bootstrap.bundle.min.js%3Ftest"></script>
}}}
I followed the execution path and the replacement happens in
{{{django.utils.encoding.filepath_to_uri}}} when {{{urllib.parse.quote}}}
is called. I think '?' should be denoted as a safe character because
otherwise, the function will replace it with a byte representation
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:2>
Django
Reporter: Adrian Garcia | Owner: nobody
Component: Template system | Version: 3.1
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Comment (by Adrian Garcia):
[https://github.com/django/django/blob/ca9872905559026af82000e46cde6f7dedc897b6/tests/staticfiles_tests/test_templatetags.py#L11
Why do we *want* to convert '?' to '%3F'?] The tests seem to indicate that
this is by design.
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:3>
Django
-------------------------------------+-------------------------------------
Component: contrib.staticfiles | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: static template | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Florian Apolloner (added)
* resolution: => wontfix
* has_patch: 1 => 0
* status: new => closed
* component: Template system => contrib.staticfiles
Comment:
Yes, this is an intended behavior, please see Florian's
[https://github.com/django/django/pull/7494#issuecomment-267820828
comment] and [https://github.com/django/django/pull/7714 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:4>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: contrib.staticfiles | Version: 3.1
Severity: Normal | Resolution: wontfix
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Adrian Garcia):
Then what's the current alternative? I need to timestamp my static files
so I can force update them in the browser and the best way I've found to
do that is to tack {{{?[timestamp]}}} on to the static import.
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: contrib.staticfiles | Version: 3.1
Severity: Normal | Resolution: wontfix
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Apolloner):
Personally I do not think there is a good reason to add a timestamp as
query param. Cache busting can be done via hashed files and if you really
must you can always write your own staticfiles backend. If you need help
there please use the normal support channels (forum, django-users mailing
list).
--
Ticket URL: <https://code.djangoproject.com/ticket/32710#comment:6>