Question

I want to run a simple test project in a subdirectory alias on our development server. The basic setup is an nginx with a location that passes everything in a subdirectory to the wsgi application.

Django obviously does not understand that it runs in an subdirectory alias, which completely destroys URL generation and parsing.
I could not find any prefix-like setting in the docs and my google fu also did not help that much… so I’m asking here instead.

The only thing I did find was the setting FORCE_SCRIPT_NAME which at least fixes the URL generation. (see: http://docs.webfaction.com/software/django/config.html#mounting-a-django-application-on-a-subpath)
Sadly this does not fix the urlconf parsing, even though the mentioned site suggests that.

Is it possible to run a django application in a subdirectory alias and if so, how?

nginx config:

server {
        location /fancyprojectname/static {
                alias /srv/fancyprojectname/static;
        }

        location /fancyprojectname/ {
                uwsgi_pass unix://var/run/uwsgi/app/fancyprojectname/socket;
                include uwsgi_params;
        }
}

Edit

So, setting “uwsgi_param SCRIPT_NAME /fancyprojectname;” in the nginx location makes FORCE_SCRIPT_NAME unnecessary – sadly the URL matching still does not work.

from django.conf.urls import patterns, include, url

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    # Uncomment the admin/doc line below to enable admin documentation:
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    url(r'^admin/', include(admin.site.urls)),
)

What I think what is happening: As the admin regex starts with “^admin” and the actual URL is “fancyprojectname/admin/”, Django can’t match the URLs correctly, even though the SCRIPT_NAME is set.

The solution

So, it was indeed a problem with SCRIPT_NAME.

The WSGI specification says the following:

SCRIPT_NAME
The initial portion of the request URL’s “path” that corresponds to the application object, so that the application knows its virtual
“location”. This may be an empty string, if the application
corresponds to the “root” of the server.

PATH_INFO
The remainder of the request URL’s “path”, designating the virtual “location” of the request’s target within the application. This may be
an empty string, if the request URL targets the application root and
does not have a trailing slash.

Nginx does not set SCRIPT_NAME automatically, so this needs to be set in any case. Afterwards PATH_INFO is wrong, because in the default setup Nginx sets this to $document_uri, which would be the full URL.

“uwsgi_modifier1 30;” tells Nginx to set UWSGI_MODIFIER_MANAGE_PATH_INFO, which in turn tells UWSGI to strip off the SCRIPT_NAME of the PATH_INFO.

The combination of these settings seem to work, as Django can now generate AND match URLs correctly.

Answer 1

This is false:

Django obviously does not understand that it runs in an subdirectory alias, which completely destroys URL generation and parsing.

Django does understand that, and deals with it transparently. The server should be setting SCRIPT_NAME itself: the fact that you find yourself using FORCE_SCRIPT_NAME shows that the problem lies in your Nginx configuration, rather than in Django.

I suspect that the issue is the use of location, rather than a more suitable directive. Unfortunately I’m no expert on Nginx/uwsgi. In Apache/mod_wsgi, you would do this:

WSGIScriptAlias /mysite /usr/local/django/mysite/apache/django.wsgi

to tell mod_wsgi that site starts at mysite, rather than the root. There is almost certainly a similar command with nginx/uwsgi.