Hi all,
I'm developing a Django site that will be served in production by
nginx-proxied gunicorn. The site is mounted on a subpath, and the nginx
config sets SCRIPT_NAME to /path to facilitate this.
This arrangement works fine with gunicorn, which I've got set up in my
Vagrant environment, but usually I like to use runserver or runserver_plus
from django-extensions during development. From nginx's perspective, there
is no difference, as both gunicorn and runserver serve at 127.0.0.1:8000.
However, while the site mounts correctly to /path under gunicorn, this is
not the case with runserver. I looked into why this is, and after some time
spent in pdb discovered what looks to be the reason.
Python's simple_server.WSGIServer sets SCRIPT_NAME to '' in its
setup_environ method. Later, simple_server.WSGIRequestHandler does the
actual header processing in its get_environ method. The culprit is this for
loop contained within:
for h in self.headers.headers:
k,v = h.split(':',1)
k=k.replace('-','_').upper(); v=v.strip()
if k in env:
continue # skip content length, type,etc.
if 'HTTP_'+k in env:
env['HTTP_'+k] += ','+v # comma-separate multiple headers
else:
env['HTTP_'+k] = v
Since SCRIPT_NAME is already in env as an empty string, the first if clause
is evaluated and the nginx-provided SCRIPT_NAME is never added to the
environment, causing things to fail down the line. Later, in the else
clause, SCRIPT_NAME becomes HTTP_SCRIPT_NAME, so it is ultimately available
to Django, but get_script_name in django.core.handlers.base (in 1.6b4,
which I'm using; .wsgi in the development version) does not take it into
consideration.
At a glance, get_script_name seems like a logical place for a quick fix,
but I'm unable to see all the implications of, say, looking at
HTTP_SCRIPT_NAME there in addition to SCRIPT_NAME. To a layman, it's also
conceivable that Django's WSGIRequestHandler could extend the get_environmethod
of its base class and add some special handling for SCRIPT_NAME
there. I'm not qualified to present either option as a recommendation,
though.
Should I file a ticket for this?
- JK
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a6464b3b-59c2-47f5-aa05-56eacb862fc7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
