Provide a way to use django under IIS

Some guy made Python for IIS possible with an ISAPI module (lot faster than CGI): http://pyisapie.sourceforge.net/ It is still confusing how can Django work with pyisapie..... And also, pyisapie has almost no support....

For this ticket to be fulfilled, somebody with access to IIS is going to have to pick one or more approaches and document it. It is clear from the mailing lists that most of the main contributors do not use IIS, so it is not going to happen without external contributions.

Most useful would be either a patch to docs/install.txt or a page in the Wiki describing what steps need to be taken.

Ok, I got some questions about PyISAPIe and Django, and I managed to write a pretty simple handler so that the two can be used together. Just download the latest release.

As far as support goes... well, I'm only one person, but I've got some stuff. Look at the readme, and the docstrings/comments on the Python part of it. Now that I've got this newest version out, I'm working on the docs and hopefully it'll be a little easier to navigate, use, and extend. Especially now that it's summer, and people are showing interest, I'll be much more available.

It would be great to se my django.core.handlers.pyisapie put into the distribution.

Take care,

Phillip

One possibility is to use flup's wsgi to AJP interface on the Django side and the IIS jk connector on the IIS side. jk has built in load balancing and failover, which is very nice. I have been using such a setup in production for a while now (with Django running on a separate box in the DMZ, though it doesn't have to be). That may be overkill for smaller operations, though.

Mark Rees' ISAPI-WSGI adapter is another option... http://isapi-wsgi.python-hosting.com/

Milestone Version 1.0 deleted

The requirement in my first comment above still holds. This will only be fixed by somebody picking a solution and documenting it.

please try this. http://wiki.woodpecker.org.cn/moin/D4I

MS release a beta of their FastCGI module:

http://www.iis.net/articles/view.aspx/IIS7/Hosting-Web-Applications/PHP/Using-FastCGI-to-host-PHP-applications-on-IIS7

Already work for PHP and according to:

http://neosmart.net/blog/2007/opensource-on-windows-and-iis/

Look like work for python. However not know how put it to work. Look like http://forums.iis.net/t/1040832.aspx python is a important plataform for final release.

I think this can be the best option.

Use FastCGI on IIS for Django guide: http://hivcc.com/python/fastcgi/en.htm.

It's possible to skip the FastCGI- as far as I see it the problem is solved more efficiently by an ISAPI extension (http://pyisapie.sourceforge.net/) and there's the option of a Django handler or WSGI.

Doesn't that pretty much solve any open issues here?

Module pyisapie functions transparently in django.core.handlers as of PyISAPIe version 1.0.107 and Django trunk revision 7025 (01-18-08).

See handler here, last committed at revision 91: https://pyisapie.svn.sourceforge.net/svnroot/pyisapie/Trunk/PyISAPIe/Python/Examples/Django/pyisapie.py

It has not yet been added to the Django repository.

Also, the WSGI handler works for 0.9x.

Both tested and working with IIS 5.x and 6.x.

I don't see why this is marked as "ready for checkin", since there's no patch attached. Moving back to previous state.

IIS ISAPI handler for django.core.handlers

This is good but not work for the real world. I'm trying to find the solution too but since our web apps must run in their separated memory space and also must serve via IIS as (at least) 2 virtual host. Both PyISAPIe and wsgi-isapi didn't support multiple virtual host.

My currently solution is: Django -> flup(AJP) -> loopback network -> JK_ISAPI -> IIS

Which is low performance (from the 2-step conversions), but work fine for me.

Replying to Chaiwat Suttipongsakul <cwt@bashell.com>:

This is good but not work for the real world. I'm trying to find the solution too but since our web apps must run in their separated memory space and also must serve via IIS as (at least) 2 virtual host. Both PyISAPIe and wsgi-isapi didn't support multiple virtual host. My currently solution is: Django -> flup(AJP) -> loopback network -> JK_ISAPI -> IIS Which is low performance (from the 2-step conversions), but work fine for me.

Why do you say they don't support virtual hosts? I'm not sure about wsgi-isapi, but nothing is stopping you from running PyISAPIe in a different memory space for each virtual host. However you decide to do it, it comes down to using a different application pool for each virtual host. You can base it on the host header if you want. In that case, it's a different web site on the same port in IIS. It doesn't need to be as complicated or slow as your setup.

I'm wondering if the attachment (pyisapie.py) is in the right place.
It allows Django to work under IIS, and DjangoOnWindowsWithIISAndSQLServer has information on setting it up.

I'm changing the component and the stage to hopefully get someone's attention and assistance in getting this handler into the framework.

pjs, please stop marking this ready for checkin; that's a distinction only a developer or triager is supposed to make. You'll succeed in getting attention, but only the bad kind.

Running Django under IIS simply isn't something most core devs can do, and without review this can't go in. Your best bet to pus things along is to point to this ticket on django-dev and ask if anyone can review it. Please be patient and understand that IIS is far from Django's preferred deployment environment and thus is likely to be met with a good deal of skepticism.

Replying to anonymous:

Replying to Chaiwat Suttipongsakul <cwt@bashell.com>:

This is good but not work for the real world. I'm trying to find the solution too but since our web apps must run in their separated memory space and also must serve via IIS as (at least) 2 virtual host. Both PyISAPIe and wsgi-isapi didn't support multiple virtual host. My currently solution is: Django -> flup(AJP) -> loopback network -> JK_ISAPI -> IIS Which is low performance (from the 2-step conversions), but work fine for me.

Why do you say they don't support virtual hosts? I'm not sure about wsgi-isapi, but nothing is stopping you from running PyISAPIe in a different memory space for each virtual host. However you decide to do it, it comes down to using a different application pool for each virtual host. You can base it on the host header if you want. In that case, it's a different web site on the same port in IIS. It doesn't need to be as complicated or slow as your setup.

Please look at this page http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer , then search for keyword 'multiple'.

Replying to Chaiwat Suttipongsakul <cwt@bashell.com>:

Replying to anonymous:

Replying to Chaiwat Suttipongsakul <cwt@bashell.com>:

This is good but not work for the real world. I'm trying to find the solution too but since our web apps must run in their separated memory space and also must serve via IIS as (at least) 2 virtual host. Both PyISAPIe and wsgi-isapi didn't support multiple virtual host. My currently solution is: Django -> flup(AJP) -> loopback network -> JK_ISAPI -> IIS Which is low performance (from the 2-step conversions), but work fine for me.

Why do you say they don't support virtual hosts? I'm not sure about wsgi-isapi, but nothing is stopping you from running PyISAPIe in a different memory space for each virtual host. However you decide to do it, it comes down to using a different application pool for each virtual host. You can base it on the host header if you want. In that case, it's a different web site on the same port in IIS. It doesn't need to be as complicated or slow as your setup.

Please look at this page http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer , then search for keyword 'multiple'.

If you look at the PyISAPIe docs (http://pyisapie.sourceforge.net/?page_id=13), you'll see that you can run multiple Django sites by using separate DLLs and having the Http package in the same folder as each vhosts's DLL.

Hope that helps a bit.

If you look at the PyISAPIe docs (http://pyisapie.sourceforge.net/?page_id=13), you'll see that you can run multiple Django sites by using separate DLLs and having the Http package in the same folder as each vhosts's DLL.

.

Actually, that is only possible when using multiple application pools. I have a thread about this here:

http://groups.google.com/group/pyisapie/browse_thread/thread/b67e861c85e1b26a?hl=en

The problem with the setup noted in the link above is that it requires manual intervention by an administrator every time a new Django app is needed. I think it would be a good idea if we could get Django working in such a way as to be conducive to multiple installs on IIS without needing admin intervention every time. This would certainly help adoption of Django in shared IIS hosting environments.

The problem, as I understand it, is that Django is relying on os.environ['DJANGO_SETTINGS_MODULE'] to load the django project. Once Django is loaded in the first PyISAPIe instance, another Django instance can not be loaded, even if os.environ['DJANGO_SETTINGS_MODULE'] is altered on each request. That is why multiple PyISAPIe instances in separate application pools is currently required.

I have a thread started to discuss the possibility of setting os.environ['DJANGO_SETTINGS_MODULE'] on each request in order to facilitate being able to run multiple Django processes in a single PyISAPIe instance.

http://groups.google.com/group/django-developers/browse_thread/thread/dfd69014daa36672

Thanks for your time and attention.

FWIW, the recent development iterations of PyISAPIe have added two things that will help the situation greatly once the next stable release is out.

- Mapping request parameters (e.g. URLs) to interpreters from a Python function
- Built-in os.environ hook, making it interpreter-local

Running Django on multiple interpreters comes with the same caveats as using multiple Python interpreters on any other application/platform, but it works and it's the best we can hope for because Django isn't designed to support completely independent sites out of the box.