Antonis,
Well truth be told I'm with uwsgi only because of the snowball effect
you're alluding to, namely we have so many options I'm like looking
on-line for what the most popular and recommended one is, and uwsgi has
a huge fan base. As to server, I opted for lighttpd only because I
already have it installed (on an OpenWRT router the LuCI interface is
driven by lighttpd by default) and so I wanted to keep to one system and
installed it on the webserver too (so I've got one set of configs/quirks
to keep my head wrapped around).
That said in the stack lighttpd->uwsgi->django for the issue I just
fixed the least culpable and probably off scot-free is uwsgi. It's
arguably a django bug.
The technical issue is that a URL like this:
http://domain.tld/script/path
is split into these two variables by Lighttpd:
SCRIPT_NAME: /script
PATH_INFO: /path
and Django wants this:
SCRIPT_NAME:
PATH_INFO: /script/path
Now if you override get_wsgi_application you can pull the switch simply
inside of the Django app you're writing with something like this in the
WSGIHandler:
environ['PATH_INFO'] = environ.get('SCRIPT_NAME','') +
environ.get('PATH_INFO','')
environ['SCRIPT_NAME'] = ''
and that works a charm. Everything rocks from there on in. It's lighttpd
that does this split and Django that has the expectations, uwsgi is just
providing the evironent lighttpd wants to pass on, and giving to
Django. It's not really at fault here in any way.
The specific issue I was hung on, was if you move this switch to
middleware, where I think it is more at home because middleware is a
well established and welcome way to inject code between Django and the
outside world (hence middle ware) then the Django url template tag
starts writing URLs like:
http://domain.tld/script/script/path
What? And it turns out that IMO it's a Django bug of sorts, because
Django squirrels SCRIPT_NAME away before calling middleware, so if you
tweak SCRIPT_NAME in middleware, Django don't care no more. Which
defeats the purpose of middleware. So IMO Django should squirrel
SCRIPT_NAME away after middleware is run!
As it happens I explicitly squirrel it away for Django in the middleware
and all comes good:
from django.core.urlresolvers import set_script_prefix
set_script_prefix(.request.environ['SCRIPT_NAME'])
And now the fiddle works in middleware too where I feel it's more at
home than with a UWSGIHandler override (i.e. theoretically is more
robust against Django evolutions).
Regards,
Bernd.
On 14/09/2017 1:27 AM, Antonis Christofides wrote:
Alas it's a tad complicated and I'll try and publish a module with
the fix some time soon (it relates to lighttpd, uwsgi, django
interactions and the management of SCRIPT_NAME and PATH_INFO
environment variables which lighttpd doesn't do to Django's
satisfaction and so it needs tweaking and I have both a uwsgi
application tweak and a middleware tweak for the job now).
Thanks for writing this.
It reminds me of a time, almost two years long, when I was using
uwsgi. Every now and then I had similar obscure issues that needed a
hell of debugging. After I migrated to Gunicorn all these issues
stopped. So I'm wondering: why are so many people using uwsgi? What am
I missing?
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/3f1f50aa-3f1e-7ee8-23bc-bfa31a316256%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
