#8927: Make Request proxy the WSGI environ
------------------------------------+---------------------------------------
Reporter: simon | Owner: nobody
Status: new | Milestone: post-1.0
Component: HTTP handling | Version: 1.0
Resolution: | Keywords:
Stage: Unreviewed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
------------------------------------+---------------------------------------
Comment (by grahamd):
Not that it helps with the general case, but when using Apache/mod_wsgi it
is quite easy to overlay different WSGI applications, with code for each
executing in same interpreter context. This can be done without modifying
Django. Doing it the Apache/mod_wsgi way though doesn't give you access to
any Django request object, but if the intent is to host an independent
WSGI application within same URL namespace, then you don't need that. Note
though that you would still be able to access the Django internals and
frameworks if the point of the WSGI application is to still be hooking
into Django internals or database layer in some way.
To get this working with Apache/mod_wsgi you just need to ensure that
WSGIApplicationGroup is set to be same value for Django and the separate
WSGI application.
{{{
Alias /media/ /usr/local/django/mysite/media/
<Directory /usr/local/django/mysite/media>
Order deny,allow
Allow from all
</Directory>
# Force all hosted applications to run in same interpreter.
WSGIApplicationGroup applications
WSGIScriptAlias / /usr/local/django/mysite/apache/django.wsgi
<Directory /usr/local/django/mysite/apache>
Order deny,allow
Allow from all
</Directory>
WSGIScriptAlias /appl /usr/local/wsgi-applications/app.wsgi
<Directory /usr/local/wsgi-applications>
Order deny,allow
Allow from all
</Directory>
}}}
Similar thing can be done in mod_python as long as you have a
mod_python/WSGI bridge installed. In case of mod_python, since default is
that virtual host uses one interpreter, rather than each application, you
may not even have to use !PythonInterpreter.
For most other hosting mechanisms you can still obviously overlay
applications under same virtual host, but each couldn't be made to readily
run in the same process and interpreter. This may not be the end of things
though as the distinct process the WSGI application is running in could
still load Django to manipulate things, just like a cron job can.
All up, being able to embed a WSGI application within Django only makes a
lot of sense if the response from the WSGI application is going to be
passed through some sort of Django output filtering mechanism for doing
stuff, or if request details and content are similarly morphed on the way
into the WSGI application. That or the WSGI application is not really a
distinct WSGI application but is more of a hybrid thing which is dependent
upon being able to access Django per request information and work on that.
In that case, why use WSGI when one could just write it to Django APIs to
begin with.
So, as much as academically this may be an interesting thing to do, most
hosting mechanisms allow you to overlay multiple applications at different
URLs. Thus, I'd suggest there really needs to be a compelling reason for
this, else it is just extra work you probably don't need.
--
Ticket URL: <http://code.djangoproject.com/ticket/8927#comment:2>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" 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/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
