#31724: django.urls.resolve ignores the FORCE_SCRIPT_NAME setting.
-------------------------------+--------------------------------------
Reporter: Pēteris Caune | Owner: nobody
Type: Bug | Status: closed
Component: Core (URLs) | Version: 3.0
Severity: Normal | Resolution: invalid
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 Florian Apolloner):
* resolution: duplicate => invalid
Comment:
Thank you for the CC, I disagree on the `duplicate` state though and will
reresolve it as `invalid`.
I think that for this issue `FORCE_SCRIPT_NAME` works as documented and
designed. The example wrongly assumes that `resolve` & `reverse` are able
to round-trip like that. This is simply not the case: `resolve` does not
operate on full URLs, but on `PATH_INFO` --
https://github.com/django/django/blob/27c09043da52ca1f02605bf28600bfd5ace95ae4/django/core/handlers/base.py#L288
. So assuming your webserver is configured to serve Django under `/foo/`
and you access `/foo/docs/` in the browser, the actual URL that Django
sees to resolve the view is `/docs/`. It is able to do so because the
webserver did configure `SCRIPT_NAME` as `/foo/` effectively telling
Django that only the part after it (ie `PATH_INFO`) is relevant. But to
`reverse` a URL properly Django does need to prepend the `SCRIPT_NAME` (or
`FORCE_SCRIPT_NAME` for that matter).
All in all `FORCE_SCRIPT_NAME` serves two specific purposes:
* If your webserver configuration is broken, `FORCE_SCRIPT_NAME` can be
used to correct the value of `SCRIPT_NAME` (though generally that might
cause wrong `PATH_INFO` as well, so I wouldn't really recommend it in this
scenario and try to fix the webserver).
* If you need to generate URLs to your views outside of a request
context. That is for example a cron job that runs without a WSGI
environment (so `SCRIPT_NAME` is never set) and the generated URL would
miss the prefix. In this case you will need to set `FORCE_SCRIPT_NAME` to
the actual `SCRIPT_NAME` that your webserver would report, so Django knows
about it in management commands etc… Under normal operations (ie when
serving views) the webserver is able to provide that information on it's
own.
--
Ticket URL: <https://code.djangoproject.com/ticket/31724#comment:3>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.d0f3623ad867c4e8c56a837c8d5d815f%40djangoproject.com.
