Two changes required to what you have done. See below.
2008/10/28 Giles Thomas <[EMAIL PROTECTED]>:
>
> Hi all,
>
> I'm trying to get mod_wsgi working with Django (1.0), and I've hit a
> problem that I can't seem to be able to solve. It's simple enough that
> I'm sure the solution is obvious and I'm just being stupid, but I've not
> been able to find anything that works, even after several hours
> searching and trying alternatives :-( Any help for a struggling
> mod_wsgi newbie would be much appreciated!
>
> The situation is: I have a simple app. It works in Django's test
> server, and is meant to serve from three base URLs - let's call them
> /admin, /foo, and /bar. My url.py therefore looks something like this:
>
> -----------------------------------------------
> urlpatterns = patterns('',
> (r'^admin/(.*)', admin.site.root),
> (r'^foo/', another.handler),
> (r'^bar/', yet.another.handler)
> )
> -----------------------------------------------
>
> In the dev server, these are available as /admin, /foo, and /bar.
>
> Now, for production, I want Apache to be serving the root (for example,
> the static pages located at /d, /e and /f) but I want /admin, /foo, and
> /bar to go to Django via mod_wsgi. After some experimentation, and
> after reference to the documentation [1] I hit upon this Apache config:
>
> -----------------------------------------------
> WSGIScriptAlias /admin /path/to/my/wsgifile/config.wsgi
> WSGIScriptAlias /foo /path/to/my/wsgifile/config.wsgi
> WSGIScriptAlias /bar /path/to/my/wsgifile/config.wsgi
> <Directory /path/to/my/wsgifile/>
Add within this Directory block:
WSGIApplicationGroup myapp
This will force all URLs to be handled within same Python sub
interpreter within the process. Without it, each WSGIScriptAlias mount
point would see a separate Python sub interpreter created for that
subset of URLs.
If this is the only Python web application you are running via
mod_wsgi, probably better to make it the main Python interpreter by
using:
WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
> </Directory>
> -----------------------------------------------
>
> The problem with this is that although access to /admin, /foo and /bar
> was being delegated to Django correctly, the URL that was passed to
> Django had the /admin (or whatever) stripped off - so its URL matching
> did not work. So, I tried using some code from the documentation to add
> it back in - in config.wsgi, I put (with mysite.settings and the
> sys.path.append changed, of course):
>
> -----------------------------------------------
> import os, sys
> sys.path.append('/usr/local/django')
> os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>
> import django.core.handlers.wsgi
>
> _application = django.core.handlers.wsgi.WSGIHandler()
>
> def application(environ, start_response):
> environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
> return _application(environ, start_response)
Close but not quite. You need to wipe out value of SCRIPT_NAME. Try:
def application(environ, start_response):
environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
environ['SCRIPT_NAME'] = ''
return _application(environ, start_response)
If you are using Django 1.0, this should be enough to make it happy.
> -----------------------------------------------
>
> I was unsure about this, as it looked like it was for versions of Django
> prior to 1.0, and anyway seemed to be a workaround for a now-fixed
> Django bug - but it seemed to work, until I tried to log in using
> Django's admin interface, under /admin. When I did that, the login page
> appeared correctly, but logging in tried to redirect me to
> /admin/admin/admin. After looking at a few other examples, my best
> guess is that pages that did redirects were somehow appending an extra
> copy of the SCRIPT_NAME at the start of the URL.
>
> I'm not sure what to make of all this but I guess my modified
> config.wsgi is completely wrong...
>
> Is that correct? And if so, what is the right way to configure mod_wsgi
> so that it handles these "root-level" URLs but also passes them down to
> the Django URL resolver?
>
> Any help would be much appreciated!
This is actually a hard one in some ways. Normal use case would be to
have root handled by Python web application, but then overlay other
URLs against static resources etc. Here you only want Python web
application to appear to be root, but not really, as only want to
expose specific URLs.
There may actually be other ways of doing this but would need to think
about. It might be able to be done using mod_rewrite rules in a tricky
way, but that could be more trouble than its worth and may still
require a fiddle in the WSGI script file.
If I come up with a way that doesn't require the fiddle in the WSGI
script file will let you know.
Graham
>
> Cheers,
>
> Giles
>
>
> [1] http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
>
> --
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> [EMAIL PROTECTED]
> +44 (0) 20 7253 6372
>
> Try out Resolver One! <http://www.resolversystems.com/get-it/>
>
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
