Thanks for the article. I followed through on making that one change to my wsgi.py configuration, and (after making two other changes) things are working on my end.
One of the other changes was to move WSGIPythonPath outside of the virtual hosts, then use both paths within the same directive (separated by a semicolon). However, there is one point of a lack of understanding on my part that's bothering me. What exactly *is* an environment variable, and why is it even needed? (Why not just read a value from a text file? - I understand these questions are on the topic of Django moreso than WSGI, so if it's too out of scope, then I'll bring it up over there rather than here.) I'm asking because each one of my website projects has the following file structure: website-name-here1.com | ---- manage.py | ---- main | ---- app1 | ---- app2 | ... Normally, when running Django's "startproject" command as per their tutorial, you get: websitenamehere1com | ---- manage.py | ---- websitenamehere1com | ---- app1 | ---- app2 | ... Personally, I found the semantics of this default way of naming things unacceptable (to my mind), so I changed it to the above. This is a convention I would strongly prefer to keep. However, this ended up with the very first Django instance running fine, and the second Django instance throwing 400 "Bad Request" errors to the client. More specifically, if I configured WSGIPythonPath to " C:/.../website_projects/*example1.com*;C:/.../website_projects/ *example2.com*", it will be example2.com that throws 400 errors. If I reverse the order of that configuration, it will be example1.com that throws 400 errors. Both website-projects had their folder named "main" (i.e. the same name), so naturally, both of their wsgi.py files had: os.environ['DJANGO_SETTINGS_MODULE'] = 'main.settings' While I had already suspected that this could cause problems (reusing the same name, "main") when running multiple instances, I do not have a detailed understanding of why. I thought that we would have one Apache process spawning two Python processes (I should note that I have next to no understanding of systems programming, Apache, WSGI, etc.), and each Python process would have its own local set of environment variables and look only within its own directory (as specified in WSGIPythonPath). It could inexplicably be the case that setting the environment variable, " DJANGO_SETTINGS_MODULE", is global, and therefore sets the value "main.settings" for both Django instances, but even if this were the case, it shouldn't matter. (I.e. they both use the same value for that variable - unless it somehow gets resolved behind the scenes to an absolute filepath.) So it might instead have to do with WSGIPythonPath being confused as to which "main.settings" it should be picking from the two paths that I configured for it. Either way, while I have a "fix", I would like to understand what is going on here and whether the above convention can be kept with some workaround. Also, off-topic; the current docs state that the WSGIPythonHome directive is not available on Windows <https://www.modwsgi.org/en/latest/configuration-directives/WSGIPythonHome.html>, but it appears to be required to have around, or else Django will throw an error. On Tuesday, February 11, 2025 at 2:12:41 AM UTC-6 Graham Dumpleton wrote: > Have a read of: > > * http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html > > and see if it answers your questions. > > Most likely since using Django any problems will be due to how > DJANGO_SETTINGS_MODULE is set. The default that project template generates > causes problems and you need to change it. > > Graham > > On 11 Feb 2025, at 2:30 pm, SC <[email protected]> wrote: > > Firstly, I'd like to thank you for maintaining this excellent utility. > > I should note that I am not a technically-versed person in these matters, > so apologies if I am slow to pick up on things. > > As for my problem, I want to host multiple Django-based websites from the > same httpd.exe process on Windows. I do not know how to go about this. > > Details on my setup: > - mod_wsgi (v5.0.0) > - Python (v3.9.2) > - Apache (v2.4.58), with the binaries being distributed by ApacheLounge > (2024-01-31 release) > - Windows Server 2012 R1 (and not R2) > - Django v4.2.10 > - I am hosting two distinct domain names (e.g. "someexample.com" and " > anotherexample.com") > - Everything is set up from scratch in the sense that I have physical > access to the machine running the web server, access to the domain names, > access to the router, etc. > - Because I am running Windows, I am running mod_wsgi in embedded mode. My > installation of Apache is mostly standard, so something like mod_python is > not installed. > > Here is the relevant snippet of Apache configuration. I am aware that it > does not run (because WSGIPythonPath cannot be in a VirtualHost directive), > but it encapsulates the logic of what I am trying to go for: > > LoadFile > "C:/Users/Administrator/AppData/Local/Programs/Python/Python39/python39.dll" > LoadModule wsgi_module > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/python_virtual_environment/lib/site-packages/mod_wsgi/server/mod_wsgi.cp39-win_amd64.pyd" > > WSGIPythonHome > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/python_virtual_environment" > > > # VIRTUAL HOST: "someexample.com" > > <VirtualHost *:80> > ServerName someexample.com > ServerAlias www.someexample.com > Redirect permanent "/" "https://someexample.com/"; > </VirtualHost> > > <VirtualHost *:443> > ServerName someexample.com > ServerAlias someexample.com > <If "%{HTTP_HOST} == 'www.someexample.com'"> > Redirect "/" "https://someexample.com/"; > </If> > > SSLEngine On > SSLCertificateFile "..." > SSLCertificateKeyFile "..." > > WSGIScriptAlias / > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > someexample.com/main/wsgi.py" > WSGIPythonPath > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > someexample.com" > > <Directory > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > someexample.com/main"> > <Files "wsgi.py"> > Require all granted > </Files> > </Directory> > > Alias "/assets/" > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > someexample.com/@assets/" > > <Directory > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > someexample.com/@assets/"> > Require all granted > </Directory> > > </VirtualHost> > > > # VIRTUAL HOST: "anotherexample.com" > > <VirtualHost *:80> > ServerName anotherexample.com > ServerAlias www.anotherexample.com > Redirect permanent "/" "https://anotherexample.com/"; > </VirtualHost> > > <VirtualHost *:443> > ServerName anotherexample.com > ServerAlias www.anotherexample.com > <If "%{HTTP_HOST} == 'www.anotherexample.com'"> > Redirect "/" "https://anotherexample.com/"; > </If> > > SSLEngine On > SSLCertificateFile "..." > SSLCertificateKeyFile "..." > > WSGIScriptAlias / > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > anotherexample.com/main/wsgi.py" > WSGIPythonPath > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > anotherexample.com" > > <Directory > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > anotherexample.com/main"> > <Files "wsgi.py"> > Require all granted > </Files> > </Directory> > > Alias "/assets/" > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > anotherexample.com/@assets/" > > <Directory > "C:/Users/Administrator/Desktop/SERVERS/web_server_production/website_projects/ > anotherexample.com/@assets/"> > Require all granted > </Directory> > > </VirtualHost> > > > If further information is needed, such as what my file structure for these > website (Django) projects look like, or how wsgi.py is configured (I > *mostly* used the default generation given by Django), I can provide > those too. > > Probably worth noting, but when starting a new project with Django, it > usually names the "main package" as whatever the project was named (usually > the name is just the website's name). Instead, I renamed that package to > "main" (and it has the same name across all websites) and updated the > appropriate references (e.g. "main.settings" inside of "wsgi.py" instead of > "someexamplecom.settings"). This is a convention I would prefer to keep, if > possible, though I am willing to revert to Django's default convention if > it is truly necessary. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/modwsgi/d2b81c58-9d22-4720-a6d3-38eec28ca9a8n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/d2b81c58-9d22-4720-a6d3-38eec28ca9a8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/modwsgi/39ecdbd5-5e04-4269-96df-86a998936e11n%40googlegroups.com.
