FORCE_SCRIPT_NAME does not work with dev server

[ElliottM]

In order to ensure that FORCE_SCRIPT_NAME would work on my production server, I first wanted to test it on the dev server. So I took an already existing project and added FORCE_SCRIPT_NAME to it., then did python manage.py runserver.

The expected result is that it would behave exactly as if I had followed all of the setup instructions for lighttpd+fcgi. (IE if I got to the
URL specified by FORCE_SCRIPT_NAME, I should get the root of the site)

The result was an absolutely unusable site.
First, I got a 404 when trying to access the site root, including the FORCE_SCRIPT_NAME. In order to get the root of the site, I have to go to "/".
Second, reverse() appears to work, because any links that are generated with URL tags or reverse() appear as expected.
Third, when I click on one of those links, I get another 404, but for a strange reason. The 404 page sent when debug=True acts as if I enter the value for FORCE_SCRIPT_NAME twice before entering the rest of the URL and submitting, which is utterly confusing.

I think either this should be fixed, the FORCE_SCRIPT_NAME should be outright ignored when using the dev server, or it should be documented that it does not work with the dev server.

Attached is a bare-bones all-default project that shows the behavior.

[Jacob]

(changed title to be less histrionic)

[Thomas Güttler]

I can reproduce this. Patch attached.

[Alex Gaynor]

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.

[Jannis Leidel]

@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.

[nkryptic]

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.

[Julien Phalip]

@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?

[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.

[Tim Graham]

Given the last comment, I'm going to close this as "won't fix."

[Natalia Bidart]

#34892 is a duplicate of this one.