Sub directories - mod_wsgi v uwsgi

Using Django
1

I have made the decision to move to uwsgi from mod_wsgi, essentially because I do not seem to be able to prevent different apps bleeding into each other (even with daemon mode), which is causing 500 errors and error log entries claiming modules not found that are not connected to the Django app that’s being called.

uwsgi seems to avoid this, and even holds out the prospect of different versions of python in venvs - something not accommodated with mod_wsgi.

However, the problem I am finding with uwsgi is that it will not recognise/handle Django apps in sub directories in the same way that mod_wsgi does. As an example:

If I have an app in /members/, with an Apache conf line like this:

WSGIScriptAlias /members /Library/WebServer/b.new.manage/b_manage/b_manage/wsgi.py

Then when I access http://wsgi.testhost/members/ I get the home page of the app, and I am abe to navigate around it without any problem. Similarly, if I access the same app via manage.py runserver… it also runs as expected.

But if I set it up with uwsgi, again with Apache:

ProxyPass /members/ http://127.0.0.1:9090/

I can get to the home page of the app with http://uwsgi.testhost/members/, but all the links/form actions when using the site point back to the server root, rather than the members directory, so a link refers to /control/ rather than /members/control/.

If I try to access a nonexistant url for the app http://*.testhost/members/controls/ the error pages for the mod_wsgi and uwsgi versions give different Request URLs:

mod_wsgi: http://wsgi.testhost/members/controls/
Request URL: http://wsgi.testhost/members/controls/

uwsgi: http://uwsgi.testhost/members/controls/
Request URL :http://127.0.0.1:9090/controls/

From which it is obvious that the host and the actual URL are not being passed to the app via the uwsgi process. It also seems to raise the prospect of the app’s settings for ALLOWED_HOSTS to be ineffective (as long as 127.0.0.1 is in the list, any host will have access).

So, after that, how do I get uwsgi to act in the same way for sub-directory apps as mod_wsgi does?

Thanks

2

I think what you are looking for are the mount and manage-script-name directives in your uwsgi.ini configuration file.

For example, in one of my projects, I have:

mount = /map=map.wsgi:application
manage-script-name = true

My entire map application then resides within the /map path of the url, and all generated urls within the application are generated with /map as the beginning of the url.

See Nginx support — uWSGI 2.0 documentation and uWSGI Options — uWSGI 2.0 documentation.

(Note: It’s been years since I’ve use Apache - we only use Nginx. I don’t know what, if anything, you might need to do with your Apache configuration to make this work.)

3

I tried those to options, but it didn’t make any difference, and a search for examples with Apache reveals sparse results, to say the least.

However, as a guess (given what I could see on the error pages), I tried this in the Apache conf:

ProxyPass /members/ http://127.0.0.1:9090/members/

ie added members/ to the proxy url.

Which, with the two options you noted, seems to fix the issue. It could be that this is only required for http mode, rather than if running uwsgi via sockets.

What you then get if you go directly to the uswgi proxy is the same content at

http://127.0.0.1:9090/ and
http://127.0.0.1:9090/members/

or

http://127.0.0.1:9090/control/ and
http://127.0.0.1:9090/members/control/

Which is a bid odd, but not an issue since the first example in both pairs is not acessible via the Apache host.

Thanks

4

Just to be clear, I found that you need to use the mount and manage-script-name settings in the uwsgi.ini and the ProxyPass with the directory on the URL in the httpd.conf for this to work properly.