unable to run newspeak in subdirectory of webserver (probably django-related)

[rejozenger]

When attempting to serve the webpages from a subdirectory (https://example.com/ns2/ instead of https://example.com), the links to the CSS and other related files are returning a 404. This is probably just a matter of properly configuring Django.

When I do not configure STATIC_URL the following is generated in the admin/ page where one is asked to login:

<link rel="stylesheet" type="text/css" href="/_static/admin/css/base.css" />
<link rel="stylesheet" type="text/css" href="/_static/admin/css/login.css" />

These do not work and will return a 404. Manually prepending the name of the subdirectory make these valid URL's.

When I add the following:

STATIC_URL = '/ns2/static/'

the following code will be generated:

<link rel="stylesheet" type="text/css" href="/ns2/static/admin/css/base.css" />
<link rel="stylesheet" type="text/css" href="/ns2/static/admin/css/login.css" />

These will return a 404.

When adding:

STATIC_URL = '/ns2/_static/'

The following will be returned:

<link rel="stylesheet" type="text/css" href="/ns2/_static/admin/css/base.css" />
<link rel="stylesheet" type="text/css" href="/ns2/_static/admin/css/login.css" />

These will generate a 404 as well (and please note: these were working when STATIC_URL was not set).

[dokterbob]

Okay, just for the record:

• If you fire a request straight to the Django webserver (gunicorn, in this case), do the static assets get loaded? If so, from what URL?
• What exactly is the configuration you use to proxy to the gunicorn server?
• When requesting the mentioned URL, what is the URL requested from the Django/gunicorn backend? (Two ways to find this out, one being more verbose logging from the proxying webserver, the other being using Django's builtin webserver instead of gunicorn, which by default logs all requests to the console, use: - newspeak runserver)

[rejozenger]

When talking to the Django directly:

rejo@trillian:~$ telnet localhost.localdomain 8000 
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
GET /admin/ HTTP/1.1

HTTP/1.1 200 OK
Server: gunicorn/0.17.2
[...]
<link rel="stylesheet" type="text/css" href="/_static/admin/css/base.css" />
<link rel="stylesheet" type="text/css" href="/_static/admin/css/login.css" />
[...]

And:

rejo@trillian:~$ telnet localhost.localdomain 8000 
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
GET /_static/admin/css/base.css HTTP/1.1

HTTP/1.1 200 OK
Server: gunicorn/0.17.2
Date: Mon, 18 Feb 2013 16:21:36 GMT
Connection: close
Last-Modified: Mon, 21 Jan 2013 21:27:17 GMT
Content-Length: 14065
Content-Type: text/css
[...]

So, that works. This is with STATIC_URL unset in the configuration.

In front of this server, I have nginx running. It has the following configuration:

    location ^~ /ns2/ {
        rewrite /ns2/(.*) /$1 break;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8000/;
        proxy_redirect http://127.0.0.1:8000/ /ns2/;
    }

As for your last question, that takes some more time and I'll get back to you tomorrow or the day after.

[dokterbob]

So summarizing:

1. Performing a request to http://127.0.0.1:8000/_static/<some_static_resource> returns a 200.
2. Performing a request to http://<nginx_server>/ns2/<some_dynamic_resource> proxies the request to http://127.0.0.1:8000/<some_resource>/ and returns a 200 as well.
3. Performing a request with STATIC_URL = '/ns2/_static/' generates URL's for static resources of the following form http://<nginx_server>/ns2/_static/<some_static_resource>, generating a 404.

This means that either 1-4 is not correct or that:

1. NGinx proxies static URL's differently from dynamic URL's as described in 2.
2. Gunicorn threads proxied requests for static files differently when proxied through NGinx as opposed to direct requests.
3. Something spooky is going on.

The most likely situation here seems to be that STATIC_URL was improperly set (i.e. the settings was never made active by restarting Django). Please provide some feedback.