Re: [Django] #7930: FORCE_SCRIPT_NAME does not work with dev server
Django
-------------------------------------+-------------------------------------
Reporter: ElliottM | Owner: nobody
Type: Bug | Status: closed
Milestone: | Component: HTTP handling
Version: SVN | Severity: Normal
Resolution: duplicate | Keywords:
Triage Stage: Design | Has patch: 1
decision needed | Needs tests: 0
Needs documentation: 0 | Easy pickings: 0
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by Alex):
* status: new => closed
* ui_ux: => 0
* resolution: => duplicate
* easy: => 0
Comment:
Discussion with Jacob: Closing as a dupe of #16360, this should be fixed
via having all of Django's HTTP handling go through a common endpoint, not
adding further cruft to the development specific server.
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: ElliottM | Owner: nobody
Version: SVN | Severity: Normal
decision needed | Needs tests: 0
Needs documentation: 0 | Easy pickings: 0
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
* status: closed => reopened
* resolution: duplicate =>
Comment:
@jacob I'm not convinced this is a duplicate of #16360 as it's about a
specific bug in how we handle the script prefix, not about adding a new
WSGI entrypoint. Re-opening.
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:7>
Django
Type: Bug | Status: reopened
Milestone: | Component: HTTP handling
Version: SVN | Severity: Normal
Resolution: | Keywords:
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------+-------------------------------
Changes (by jezdez):
* stage: Design decision needed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:8>
Django
Type: Bug | Status: reopened
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 guettli):
* cc: hv@… (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:9>
Django
-------------------------------+------------------------------------
Reporter: ElliottM | Owner: nobody
Type: Bug | Status: reopened
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
-------------------------------+------------------------------------
* cc: nkryptic (added)
Comment:
Im attaching a patch, but you can also view the work on Github at
https://github.com/nkryptic/django/commit/71921091981fc187831550a37d5b65cf76039b16
I think this issue is more widespread than just the development
`runserver` command. Changing `FORCE_SCRIPT_NAME` will also break the
`LiveServerTestCase`. Finally, it looks like there is an issue if you
change `FORCE_SCRIPT_NAME` with `override_settings` while testing, if the
test does any request processing and therefore calls
`django.core.urlresolvers.set_script_prefix`. SInce `set_script_prefix`
changes the global `_prefixes` object, it doesn't get unset and will
remain present for tests afterwards. The patch includes a test signal
handler for `setting_changed` which addresses this.
What the patch does is add a new `UrlPrefixedAwareHandler` that is applied
in the base `runserver` command, wrapping the normal handler. This wsgi
middleware only performs when `FORCE_SCRIPT_NAME` is present. If it is,
the script will ensure incoming requests begin with `FORCE_SCRIPT_NAME`
and then strip it from then environ's `PATH_INFO` before passing environ
on to the normal handler. If the incoming request doesn't begin with
`FORCE_SCRIPT_NAME`, a 400 Bad Request is raised.
Also, the `StaticFilesHandler` has to become aware of `FORCE_SCRIPT_NAME`,
as it will check both the `PATH_INFO` from the incoming environ and also
`request.path` later (which will be prepended with `FORCE_SCRIPT_NAME`).
I don't know if the new tests written are enough to ensure this patch's
validity, or if there is need for additional documentation from this. I
open to suggestions. I'd also be happy to claim this issue, although I
didn't see an 'accept' option, even though it is owned by nobody.
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:10>
Django
-------------------------------+------------------------------------
Reporter: ElliottM | Owner: nobody
Component: HTTP handling | Version: master
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
-------------------------------+------------------------------------
Comment (by julien):
@nkryptic: Thanks for your work on this patch. I've just quickly tried out
your patch but it seems like it only works for the home page (e.g.
'/PREFIX/'). Every other URL (e.g. '/PREFIX/blah/') returns a 404.
Am I missing something?
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:12>
Django
-------------------------------+------------------------------------
Reporter: ElliottM | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: master
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
-------------------------------+------------------------------------
Comment (by nkryptic):
@julien, when I wrote the patch, it was effectively a port of code I was
using in local development so that my settings with runserver would mirror
my production settings. It worked on my entire project then and the tests
all passed. I developed the practice because, at some previous time, my
nginx+gunicorn production setup wouldn't work without setting
force_script_name. My guess it is was an issue with gunicorn, which has
since been fixed.
After some discussion with @apollo13 on IRC, he pointed out that
force_script_name was legacy and it's use intended only to address broken
web servers, but that normal setups should never require it. I then
tested with nginx+gunicorn using only SCRIPT_NAME in my nginx.conf (with a
few others) and everything worked (and has continued to work) without
issue since. Given what @apollo13 said, and that I don't need
force_script_name in production, I changed my dev practices to simply not
use prefixed urls, as I considered this to be a dead end.
If there is some desire for this to work going forward, I'll be happy to
figure out why it's not working now and update the patch as needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:13>
Django
-------------------------------+------------------------------------
Reporter: ElliottM | Owner: nobody
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Given the last comment, I'm going to close this as "won't fix."
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:14>
Django
-------------------------------+------------------------------------
Reporter: ElliottM | Owner: nobody
Type: Bug | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by Natalia Bidart):
#34892 is a duplicate of this one.
--
Ticket URL: <https://code.djangoproject.com/ticket/7930#comment:15>