Make Request proxy the WSGI environ

The idea here is that there should be easy access to a wsgi environ like dictionary, to make calling wsgi applications from within django trivial.

I would even propose that making a call_wsgi_app function that grabs the environ, creates a start_response callable, calls the wsgi app, and returns the response properly.

This would let users write code like:

def someview(request, *args)

do_something(args) return call_wsgi_app(wsgi_app, request)

This would allow people who use django with SQLAlchemy to user RUM (A django admin like wsgi app) from a veiw, or to use some SOAP wsgi application, or a TurboGears?? app, or whatever they want in a Django view.

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.

FWIW, one valid reason suggested over in discussion on mod_wsgi list about this has been the need to easily wrap a separate WSGI application within Django session based login mechanism.

One other thing where this came up is with hosting a Mercurial application (push/pull interface) within Django (that is, same url-space, same authentication/authorization). That kind of thing would be massively easier if Django provided some bits to do this kind of thing.

Milestone post-1.0 deleted

Thought I'd throw in my 2c now that this is on the radar for a GSoC project...

I have a WSGI application that accepts file uploads as standard multipart/form-data, and I want to expose it from within a larger Django application. This is complicated by the fact that I need to trigger both Django's authentication framework *and* Django's file upload handlers, to validate and monitor the uploads before they hit the WSGI app.

My current solution is pretty yuck and duplicates a lot of logic from multipartparser.py, but it's been working well for me so far. The idea is to set environ['wsgi.input'] to a wrapper object, which knows about Django's POST and FILE dictionaries and can convert these to/from a standard readable input stream as required by WSGI. It's on github if you want to have a look, adapted from some work by Travis Parker:

http://github.com/rfk/django/blob/f96eb6068552e228f705beda9c8181db2079a797/django/wsgi/wsgi_to_django.py

This kind of thing might be far more complicated than you're willing to support in Django, but is worth thinking about at least.

Cheers,

Ryan

Hi.

I need to get this fixed so we can use Repoze software in the Django app we maintain at work. I already started working on it and wanted to you know so we won't duplicate efforts.

Please feel free to assign this ticket to me if you want - I'll propose a patch once I'm done anyway.

Cheers,

• Gustavo.

Patch to make the WSGI available where it's missing

Please let me know what you think about the patch. I found that request.environ was usually defined, but was missing in mod_python, so I just made it available everywhere no matter the handler being used.