SCRIPT_NAME is not an HTTP header, it cannot be sent from nginx to your runserver since it is only part of the CGI/WSGI environment, not the headers. That said you could still add a command line option to set SCRIPT_NAME within runserver, but that's slightly different than what you described I think.
--Noah JK Laiho <[email protected]> wrote: >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. -- 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/62d962b8-0364-40a5-838f-621945832bb8%40email.android.com. For more options, visit https://groups.google.com/groups/opt_out.
