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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
