[Fixed]-Run django app via nginx+uwsgi in a subpath

by

8đź‘Ť

âś…

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.

👤Daniel Roseman

7đź‘Ť

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:

👤lofidevops

7đź‘Ť

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.

👤Shane

0đź‘Ť

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

👤Ivan Shatsky

Leave a comment