#35985: FORCE_SCRIPT_NAME ignored when running reverse() on non-main thread
-------------------------------------+-------------------------------------
Reporter: Pēteris Caune | Owner: (none)
Type: | Status: closed
Cleanup/optimization |
Component: Core (URLs) | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):
* summary:
SCRIPT_NAME / FORCE_SCRIPT_NAME ignored when running reverse() on non-
main thread
=> FORCE_SCRIPT_NAME ignored when running reverse() on non-main thread
Old description:
> I've configured my Django project to run on a subpath (under
> `example.org/some_prefix` instead of `example.org`).
>
> The project has a management command which generates URLs using
> `django.urls.reverse()`.
>
> Since the management command cannot read SCRIPT_NAME from WSGI
> parameters, the project has `FORCE_SCRIPT_NAME = "/some_prefix"` in
> settings.py.
>
> The management command generates URLs that include the prefix as expected
> if the code runs on main thread. But if the management command spawns a
> thread, the code running on thread **generates URLs without the prefix**.
>
> I'm not sure but I think this is related to `hc.urls.base._prefix` being
> a `Local` object. I'm guessing it, as the name suggests, does not share
> data between threads. Even though `set_script_prefix` is called on main
> thread, the other threads do not see it.
>
> A simple workaround is for the user to call `set_script_prefix` by
> themselves:
>
> {{{
> from django.conf import settings
> from django.urls import set_script_prefix
>
> def this_will_be_run_on_thread():
> if settings.FORCE_SCRIPT_NAME:
> set_script_prefix(settings.FORCE_SCRIPT_NAME)
> # do work here
> }}}
>
> But perhaps there's something Django could do here as well:
>
> * perhaps, change django.urls implementation so that threads do share the
> script prefix storage?
> * if there are disadvantages to that, mention this gotcha in the
> documentation
>
> I'm happy to provide a dummy project demonstrating the issue if that
> would be helpful.
New description:
I've configured my Django project to run on a subpath (under
`example.org/some_prefix` instead of `example.org`).
The project has a management command which generates URLs using
`django.urls.reverse()`.
Since the management command cannot read SCRIPT_NAME from WSGI parameters,
the project has `FORCE_SCRIPT_NAME = "/some_prefix"` in settings.py.
The management command generates URLs that include the prefix as expected
if the code runs on main thread. But if the management command spawns a
thread, the code running on thread **generates URLs without the prefix**.
I'm not sure but I think this is related to `django.urls.base._prefixes`
being a `Local` object. I'm guessing it, as the name suggests, does not
share data between threads. Even though `set_script_prefix` is called on
main thread, the other threads do not see it.
A simple workaround is for the user to call `set_script_prefix` by
themselves:
{{{
from django.conf import settings
from django.urls import set_script_prefix
def this_will_be_run_on_thread():
if settings.FORCE_SCRIPT_NAME:
set_script_prefix(settings.FORCE_SCRIPT_NAME)
# do work here
}}}
But perhaps there's something Django could do here as well:
* perhaps, change django.urls implementation so that threads do share the
script prefix storage?
* if there are disadvantages to that, mention this gotcha in the
documentation
I'm happy to provide a dummy project demonstrating the issue if that would
be helpful.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35985#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070193abcc1e36-817259e1-80cd-4f15-ae9b-95bcfd4a16aa-000000%40eu-central-1.amazonses.com.
