That particular issue may be a lighttpd issue, but my question is more general. Unfortunately I don't remember the kind of trouble I was having with uwsgi.
Are there any people who have used both uwsgi and gunicorn and have a preference for the former? What benefits have they seen? Antonis Christofides http://djangodeployment.com On 2017-09-13 18:36, Melvyn Sopacua wrote: > You're missing the fact that it's the scgi module of lighttpd is what > is causing it. uwsgi shouldn't fix it, as it has no idea if this is > intentional, for example when using mounts [1]. > As can be seen in the WSGI spec, the WSGI client (uwsgi / gunicorn / > whathaveyou) should trust what is provided here [2]. If gunicorn does > it differently, it will prevent you from mounting an app in a virtual > location, say "/django/". > > [1] > http://uwsgi-docs.readthedocs.io/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info > [2] https://www.python.org/dev/peps/pep-0333/#environ-variables > > On Wed, Sep 13, 2017 at 5:27 PM, Antonis Christofides > <anto...@djangodeployment.com> 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? >> >> Antonis Christofides >> http://djangodeployment.com >> >> >> On 2017-09-13 15:35, Bernd Wechner wrote: >> >> Well, not a lot of insight from the broader community on this one, but a >> warm thank you to Melvyn Sopacua who took the time to think about it a bit >> and apply his experience which led me to: >> >> /usr/local/lib/python3.5/dist-packages/django/urls/base.py >> >> where I could instrument Django a bit and find out how and why it was adding >> this bizarre prefix to the urls. >> >> 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). >> >> Regards, >> >> Bernd. >> >> >> Bernd Wechner wrote: >> >> OK, I've more or less solved my original problems in deploying in this >> space. Well I've deployed and am happy. >> >> BUT, I am still bamboozled by something and wonder if anyone has any clue or >> insights to share? >> >> I have these two urlpatterns defined: >> >> url(r'^list/(?P<model>\w+)', views.view_List.as_view(), name='list') >> url(r'^view/(?P<model>\w+)/(?P<pk>\d+)$', views.view_Detail.as_view(), >> name='view'), >> >> Works a charm with these template tags: >> >> <a href="{% url 'list' 'Player' %}">List Players</a> >> <a href="{% url 'view' model_name o.pk %}">View Player {{ o }} </a> >> >> That url tag produces these URLs: >> >> http://127.0.0.1:8000/list/Player >> http://127.0.0.1:8000/view/Player/1 >> >> And it works. I click the links and they work. Well I've been developing >> this way for a couple of years and it's always worked ;-). it's great! >> >> BUT, after deploying, this resolves on the home page to: >> >> http://leaderboard.space/list/Player >> >> And when I click it it works! Awesome. Happy as. Great stuff. Gotta love >> Django! >> >> BUT, if is open this page: >> >> http://leaderboard.space/view/Player/1 >> >> It renders fine, I see a great view of player 1. >> >> BUT, on that page is the good old list link from above, namely: >> >> <a href="{% url 'list' 'Player' %}">List Players</a> >> >> and on the dev site this resolves to: >> >> http://127.0.0.1:8000/list/Player >> >> and here is the thing I'm stuck on! On the deployed site it renders as: >> >> http://leaderboard.space/view/list/Player >> >> What? Where did that 'view' come from? Of course I click it I get a 404 >> error: >> >> Page not found (404) >> Request Method: GET >> Request URL: http://leaderboard.space/view/list/Player >> Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in >> this order: >> >> ^$ [name='home'] >> ^admin/ >> ^login/$ [name='login'] >> ^logout/$ [name='logout'] >> ^fix [name='fix'] >> ^unwind [name='unwind'] >> ^check [name='check'] >> ^rebuild [name='rebuild'] >> ^kill/(?P<model>\w+)/(?P<pk>\d+)$ [name='kill'] >> ^list/(?P<model>\w+) [name='list'] >> ^view/(?P<model>\w+)/(?P<pk>\d+)$ [name='view'] >> ^add/(?P<model>\w+)$ [name='add'] >> ^edit/(?P<model>\w+)/(?P<pk>\d+)$ [name='edit'] >> ^delete/(?P<model>\w+)/(?P<pk>\d+)$ [name='delete'] >> ^leaderboards [name='leaderboards'] >> ^json/game/(?P<pk>\d+)$ [name='get_game_props'] >> ^json/leaderboards [name='json_leaderboards'] >> ^static\/(?P<path>.*)$ >> >> The current path, view/list/Player, didn't match any of these. >> >> clearly. Because I don't look for this bizarre and newly introduced 'view'. >> >> Now to be clear, I have a way around this, but I am not looking for a >> workaround here, I'm fishing for any clues that help me understand how the >> url template tag generates its output and when and why it inserts a string >> like this that seems to be the name of the view that the link is on! >> >> Mystery++ and PITA. >> >> Regards, >> >> Bernd. >> >> >> -- >> 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/d3a95675-8137-ab90-54ea-b3e44ae6f53d%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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/f1ca6e9e-4948-dcd5-cf28-1b95b40eabce%40djangodeployment.com. >> >> For more options, visit https://groups.google.com/d/optout. > > -- 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/ca1e2b9e-84db-044f-753c-3fb62e93b699%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
