Run django app via nginx+uwsgi in a subpath

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.

Answer 2

This approach (which worked in 2016) is now deprecated. It may still apply if you are running LTS software.

"Note: ancient uWSGI versions used to support the so called “uwsgi_modifier1 30” approach. Do not do it. it is a really ugly hack"

See Hosting multiple apps in the same process (aka managing SCRIPT_NAME and PATH_INFO

Original answer

If this Nginx location block works when hosting the Django site at http://www.example.com/ (your base domain):

location / {
    uwsgi_pass unix:/tmp/fancyprojectname.socket;
    include /etc/nginx/uwsgi_params;
}

Then this will work at http://www.example.com/subpath/ (a subpath on your base domain):

location /subpath {
    uwsgi_pass unix:/tmp/fancyprojectname.socket;
    uwsgi_param SCRIPT_NAME /subpath; # explicitly set SCRIPT_NAME to match subpath
    uwsgi_modifier1 30; # strips SCRIPT_NAME from PATH_INFO (the url passed to Django)
    include /etc/nginx/uwsgi_params;
}

...and there is no need to set FORCE_SCRIPT_NAME in your Django settings.

References:

• Strayer's original comments and solution as posted in question.
• https://uwsgi-docs.readthedocs.org/en/latest/Nginx.html
• https://www.python.org/dev/peps/pep-0333/ (full WSGI specification)

Answer 3

Now that uwsgi_modifier1 30 is removed in the latest versions of Nginx and uWSGI (and I didn't feel like using some hacky rewrite rules), I had to find a newer method to get it working:

uWSGI config:

[uwsgi]
# Requires PCRE support compiled into uWSGI
route-run = fixpathinfo:

Nginx config:

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

    location /fancyprojectname {
        uwsgi_pass unix://var/run/uwsgi/app/fancyprojectname/socket;
        uwsgi_param SCRIPT_NAME /fancyprojectname; # Pass the URL prefix to uWSGI so the "fixpathinfo:" route-rule can strip it out
        include uwsgi_params;
    }
}

IF THAT DOESN'T FIX IT: Try installing libpcre and libpcre-dev, then reinstall uwsgi with pip install -I --no-cache-dir uwsgi. uWSGI's internal routing subsystem requires the PCRE library to be installed before uWSGI is compiled/installed. More information on uWSGI and PCRE.

Answer 4

One can made both SCRIPT_NAME and PATH_INFO uWSGI variables to be filled correctly by nginx itself without setting modifier1 header packet (which is deprecated and doesn't work with python3 anymore) or relying on PCRE support in uWSGI server using the route-run parameter. Instead you can use the following trick rewriting an $uri nginx internal variable before including uwsgi_params file:

location /app_prefix/ {
    rewrite ^/app_prefix(.*) $1 break;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /app_prefix;
    uwsgi_pass unix:/path/to/socket;
}

An alternative solution can be using the manage-script-name uWSGI server parameter (command line example, config file example).