[Django] #36653: FORCE_SCRIPT_NAME is not respected for static URLs

33 views
Skip to first unread message

Django

unread,
Oct 9, 2025, 5:07:09 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Type: Bug
Status: new | Component:
| contrib.staticfiles
Version: 5.2 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
The documentation for the `STATIC_URL` setting states:
> If `STATIC_URL` is a relative path, then it will be prefixed by the
server-provided value of `SCRIPT_NAME` (or / if not set). This makes it
easier to serve a Django application in a subpath without adding an extra
configuration to the settings.

However, when using `FORCE_SCRIPT_NAME`, the value of `STATIC_URL` when
serving requests is never updated appropriately. This breaks URL
construction via `django.templatetags.static.static` (used in templates as
`{% static ... %}`).

For example, this causes the Django Admin pages to break when using
`FORCE_SCRIPT_NAME` to serve Django under a subpath. Generally, using
`FORCE_SCRIPT_NAME` causes Django to behave incorrectly: view URLs are
constructed to respect it, static URLs are constructed to not respect it.

I believe that this bug likely also affects static URLs when using the
`SCRIPT_NAME` WSGI environment variable too, but I haven't verified that
yet.

----
There is definitely some history here, but I believe previous bug reports
have struggled to articulate this problem.

Long ago, the following reports were made, which I believe are ''not''
relevant to this problem (but I'm summarizing them because they've been
claimed to be duplicates of this problem):
* #7930 only discussed view URLs (and using `reverse()`); this now works
as expected, but static URLs are still broken
* #30634 is probably irrelevant; it claimed vague problems with
`SCRIPT_NAME` and runserver; the problem here is general to all servers,
including both runserver and WSGI
* #31724 is probably a true duplicate of #7930

More recently, we've seen:
* #34892 is probably the same as this problem, but the reporter struggled
to articulate the behavior and I believe it was mistakenly closed as a
duplicate of the aforementioned old issues
* #35985 claimed that this is problem is limited to using threading within
management commands, then got derailed by the niche use case and
suggestions around the low-level `set_script_prefix` API; it does contain
the very useful suggestion to invoke `django.setup()` in each thread,
which I don't believe was adequately explored

---
I believe that I understand the exact cause of the bug. Note, my use of
some lifecycle events and specific thread names may be limited to the
runserver case, but the exact same behaviors manifest with WSGI (and I
believe that equivalent things are occurring with a multiprocess
lifecycle).

1. `django.setup()` is
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/management/__init__.py#L395
called very early by runserver]
2. `django.setup()`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/__init__.py#L20-L23
calls `set_script_prefix`]
3. `set_script_prefix`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/urls/base.py#L120C5-L126C20
correctly sets] `django.urls.base._prefixes.value`, but only for the
current thread (since `_prefixes` is a thread-local object)
4. a new thread, `django-main-thread`,
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/utils/autoreload.py#L666-L670
is spawned]; again, I believe (and can locate if necessary) that an
equivalent event also happens in a WSGI lifecycle
5. `check_url_settings`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/checks/urls.py#L108-L109
runs and accesses `settings.STATIC_URL`]; importantly, this is the first
time in the startup lifecycle that `settings.STATIC_URL` has ever been
accessed
6. `django.conf.__getattr__`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/conf/__init__.py#L82-L83
has special logic for `STATIC_URL`], so it calls the staticmethod
`LazySettings._add_script_prefix`
7. `LazySettings._add_script_prefix`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/conf/__init__.py#L134
calls `get_script_prefix`]
8. `get_script_prefix`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/urls/base.py#L129-L135
looks at `django.urls.base._prefixes.value`], but it's running in a new
thread (step 4), so it doesn't contain the `FORCE_SCRIPT_NAME` value (step
3) and returns `"/"`
9. `django.conf.__getattr__` (step 6) permanently caches the incorrect
value of `settings.STATIC_URL` in `LazySettings.__dict__` (which is not
thread-local); all future requests for `settings.STATIC_URL` will receive
the incorrect value (`"/"`, instead of `settings.FORCE_SCRIPT_NAME`)
10. The first HTTP request comes in
11. `WSGIHandler.__call__`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/handlers/wsgi.py#L121
calls] `get_script_name`
12. `get_script_name`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/handlers/wsgi.py#L162-L163
correctly returns] `settings.FORCE_SCRIPT_NAME`
13. `WSGIHandler.__call__`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/handlers/wsgi.py#L121
calls] `set_script_prefix` with the correct argument (the value
`settings.FORCE_SCRIPT_NAME`)
14. `set_script_prefix` (just as in step 3)
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/urls/base.py#L120C5-L126C20
finally sets] `django.urls.base._prefixes.value` (which, remember, is a
thread-local variable, but will persist for at least the remainder of this
HTTP request) with the correct value
15. While rendering the HTTP response, a template or some code calls
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/templatetags/static.py#L174-L179
`django.templatetags.static`]; assume that the app
`"django.contrib.staticfiles"` is installed and configured to use some
subclass of `StaticFilesStorage` (which is Django's typical configuration)
16. `django.contrib.staticfiles.storage.staticfiles_storage.url()`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/templatetags/static.py#L129
is called]
17. `staticfiles_storage` (an instance of `StaticFilesStorage`)
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/files/storage/handler.py#L46
is lazily constructed]
18. `StaticFilesStorage.__init__` is called; assume it has no arguments
from `settings.STORAGES["staticfiles"]["OPTIONS"]
([https://docs.djangoproject.com/en/5.2/ref/settings/#storages this is
Django's default])
19. `StaticFilesStorage.__init__`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/contrib/staticfiles/storage.py#L27-L30
defaults to set its `self._base_url`] to `settings.STATIC_URL`, but
`settings.STATIC_URL` returns an incorrect value (step 9)
20. Continuing the call in step 16, `FilesystemStorage.url`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/files/storage/filesystem.py#L212
forms the actual URL] from `self.base_url`
21. `self.base_url`,
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/core/files/storage/filesystem.py#L47-L51
a cached property], relies on the incorrect `self._base_url`
22. A static file URL is returned with the incorrect base URL, not
respecting `settings.FORCE_SCRIPT_NAME`
23. Subsequent HTTP requests skip steps 17-19, but otherwise reply the
work from step 10 onwards (and also result in incorrect static URLs)

In summary, the problem is that although there's code to attempt to set
(via `set_script_prefix`) the correct script name both on Django's startup
and again on every individual HTTP request, `settings.STATIC_URL` slips
between a lifecycle "crack" and ends up with the wrong value (which
doesn't incorporate the script name, ''contrary to its documentation''),
which persists over the entire request-response lifecycle.
--
Ticket URL: <https://code.djangoproject.com/ticket/36653>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 9, 2025, 5:08:47 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Brian Helba:

Old description:
New description:
----
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:1>

Django

unread,
Oct 9, 2025, 5:11:58 PM10/9/25
to django-...@googlegroups.com
the function] `django.templatetags.static`; assume that the app
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:2>

Django

unread,
Oct 9, 2025, 5:13:18 PM10/9/25
to django-...@googlegroups.com
New description:

The documentation for the `STATIC_URL` setting states:
> If `STATIC_URL` is a relative path, then it will be prefixed by the
server-provided value of `SCRIPT_NAME` (or / if not set). This makes it
easier to serve a Django application in a subpath without adding an extra
configuration to the settings.

However, when using `FORCE_SCRIPT_NAME`, the value of `STATIC_URL` when
serving requests is never updated appropriately. This breaks URL
construction via `django.templatetags.static.static` (used in templates as
`{% static ... %}`).

For example, this causes the Django Admin pages to break when using
`FORCE_SCRIPT_NAME` to serve Django under a subpath. Generally, using
`FORCE_SCRIPT_NAME` causes Django to behave incorrectly: view URLs are
constructed to respect it, static URLs are constructed to not respect it.

I believe that this bug likely also affects static URLs when using the
`SCRIPT_NAME` WSGI environment variable too, but I haven't verified that
yet.

----
There is definitely some history here, but I believe previous bug reports
have struggled to articulate this problem. I'm including all of the below
detail in the hope that this issue will be understood well enough to
acknowledge it as a legitimate bug.
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:3>

Django

unread,
Oct 9, 2025, 5:36:40 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Brian Helba):

In terms of policies for a solution, although `settings.FORCE_SCRIPT_NAME`
might practically be constant over Django's lifecycle, it's completely
allowed by WSGI for the value of the `SCRIPT_NAME` environment variable to
change on each request (and there's code in step 13 to support this). So,
I think it follows that that `settings.STATIC_URL` should also be allowed
to change on each new HTTP request. I'd encourage this path.

If we require that `settings.STATIC_URL` shouldn't change, it allows for
some simpler fixes that only require `STATIC_URL` to eventually respect
`FORCE_SCRIPT_NAME` and maybe the first-presented value of a `SCRIPT_NAME`
environment variable. I think this would lead to confusing behavior for
anyone using `SCRIPT_NAME`.

Alternatively, we could change
[https://docs.djangoproject.com/en/5.2/ref/settings/#static-url the
documentation] for `STATIC_URL` to state that it doesn't respect
`SCRIPT_NAME`, but that would be a larger policy change (not a simple
bugfix) and it'd lead to a slipperly slope of just dropping all support
for `SCRIPT_NAME` / `FORCE_SCRIPT_NAME`, etc. (which is out of scope for
this issue). I think this change is too ambitious and would remove useful
functionality for serving Django within subpaths behind reverse proxies,
so I don't support it.

----
I see two reasonable changes:
1. Change the behavior (in step 6-9) of `settings.STATIC_URL`, so it's not
permanently cached. Each access of `settings.STATIC_URL` would recomputed
the value, using `LazySettings._add_script_prefix`.
2. Change `set_script_prefix` to reach into `settings` and invalidate the
cache of `STATIC_URL`, causing step 13 to have its full intended effect.
This is technically more efficient than having no cache of `STATIC_URL`,
but introduces additional circularity in the relationship between all
these methods and further breaks the abstraction of `LazySettings` (as
`LazySettings` caches itself internally, but has its cache invalidated
externally).
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:4>

Django

unread,
Oct 9, 2025, 5:37:27 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Brian Helba:

Old description:

> The documentation for the `STATIC_URL` setting states:
> > If `STATIC_URL` is a relative path, then it will be prefixed by the
> server-provided value of `SCRIPT_NAME` (or / if not set). This makes it
> easier to serve a Django application in a subpath without adding an extra
> configuration to the settings.
>
> However, when using `FORCE_SCRIPT_NAME`, the value of `STATIC_URL` when
> serving requests is never updated appropriately. This breaks URL
> construction via `django.templatetags.static.static` (used in templates
> as `{% static ... %}`).
>
> For example, this causes the Django Admin pages to break when using
> `FORCE_SCRIPT_NAME` to serve Django under a subpath. Generally, using
> `FORCE_SCRIPT_NAME` causes Django to behave incorrectly: view URLs are
> constructed to respect it, static URLs are constructed to not respect it.
>
> I believe that this bug likely also affects static URLs when using the
> `SCRIPT_NAME` WSGI environment variable too, but I haven't verified that
> yet.
>
> ----
> There is definitely some history here, but I believe previous bug reports
New description:

[https://docs.djangoproject.com/en/5.2/ref/settings/#static-url The
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:5>

Django

unread,
Oct 9, 2025, 5:44:11 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Brian Helba):

Finally, I see that `LazySettings`
[https://github.com/django/django/blob/1167cd1d639c3fee69dbdef351d31e8a17d1fedf/django/conf/__init__.py#L82-L83
also caches] `MEDIA_URL` in a similar way. I haven't fully thought about
the impact on the default (a.k.a. media) storage, but there may be similar
issues there too. I'm trying to keep this issue more focused on static
files, as they definitely cause breakages with the default Django Admin.
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:6>

Django

unread,
Oct 9, 2025, 5:50:18 PM10/9/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Brian Helba:

Old description:

--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:7>

Django

unread,
Oct 13, 2025, 1:09:33 PM10/13/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+------------------------------------
Changes (by Jacob Walls):

* cc: Florian Apolloner (added)
* stage: Unreviewed => Accepted

Comment:

Thanks for the thorough report. Reproduced 👍

Regression in 7dbbe65647a54283fadf2c51f11a750a74425d7b given the side
effects left by the system check in step 4 and
`django.contrib.staticfiles.utils.check_settings`, which does something
similar.

Reverting that commit fixes the `FORCE_SCRIPT_NAME` case; I would expect
it to fix an invariant `SCRIPT_NAME` as well. I think triage on #34028
missed this, since we can't just document that prefixes shouldn't be set
outside the request/response cycle and expect this to work, since these
two system checks are *also* outside the request/response cycle.

See this comment
[https://github.com/django/django/pull/13120#issuecomment-1405259988
anticipating a revert] when someone posted on the closed PR, also
encouraging us not to focus on varying values for `SCRIPT_NAME`:

> There is an open ticket to that extend somewhere and I feel we might
need to have to revert this. That said, settings are considered to be
static, so if this changes per request Django will not be happy either way
since the value was already passed to default_storage and used to
instantiate the backend :/

Would you like to submit a PR?
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:8>

Django

unread,
Oct 13, 2025, 1:13:09 PM10/13/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+------------------------------------
Changes (by Jacob Walls):

* cc: Klaas van Schelven, David Sanders (added)

Comment:

/cc some folks from #34028
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:9>

Django

unread,
Oct 13, 2025, 2:12:09 PM10/13/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+------------------------------------
Comment (by Florian Apolloner):

I fear I don't have anything useful to add, personally I think we should
burn it down and rebuild (the whole `SCRIPT_NAME`/`FORCE_SCRIPT_NAME`
interaction with static files etc). For context I can offer
https://code.djangoproject.com/ticket/35985#comment:5 which provides some
"workarounds" -- "workarounds" in quotes since I don't think this is a
workaround but how it should actually behave :D
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:10>

Django

unread,
Oct 15, 2025, 12:22:26 PM10/15/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+------------------------------------
Reporter: Brian Helba | Owner: (none)
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+------------------------------------
Changes (by Dan LaManna):

* cc: Dan LaManna (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:11>

Django

unread,
Nov 19, 2025, 2:29:22 AM11/19/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: Xingzhe
| Li
Type: Bug | Status: assigned
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Xingzhe Li):

* owner: (none) => Xingzhe Li
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:12>

Django

unread,
Nov 20, 2025, 1:37:30 AM11/20/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: Xingzhe
| Li
Type: Bug | Status: assigned
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by VIZZARD-X):

Hi, I'd like to start working on this issue.

Before I begin, just checking to avoid duplicating effort — is anyone
currently preparing a patch or a PR for this? If not, I'll move ahead with
reproducing the bug and drafting a fix.

Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:13>

Django

unread,
Nov 20, 2025, 2:18:19 AM11/20/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: Xingzhe
| Li
Type: Bug | Status: assigned
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Xingzhe Li):

Replying to [comment:13 VIZZARD-X]:
> Hi, I'd like to start working on this issue.
>
> Before I begin, just checking to avoid duplicating effort — is anyone
currently preparing a patch or a PR for this? If not, I'll move ahead with
reproducing the bug and drafting a fix.
>
> Thanks!

Yes, I am working on it. You can find issues people are not working on by
checking whether or not they have been assigned.
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:14>

Django

unread,
Nov 23, 2025, 8:03:22 PM11/23/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: Xingzhe
| Li
Type: Bug | Status: assigned
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Xingzhe Li):

* has_patch: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:15>

Django

unread,
Nov 24, 2025, 7:01:08 AM11/24/25
to django-...@googlegroups.com
#36653: FORCE_SCRIPT_NAME is not respected for static URLs
-------------------------------------+-------------------------------------
Reporter: Brian Helba | Owner: Xingzhe
| Li
Type: Bug | Status: assigned
Component: contrib.staticfiles | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* needs_better_patch: 0 => 1

Comment:

Per Florian's comment on PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/36653#comment:16>
Reply all
Reply to author
Forward
0 new messages