Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#2039 closed New feature (needsinfo)

Provide a way to use django under IIS

Reported by: mamcx Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: iis, fastcgi, isapi
Cc: Triage Stage: Someday/Maybe
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Exist a lack of information in how use python in general and django in particular with IIS.

IIS is the second most used webserver according:

http://news.netcraft.com/archives/web_server_survey.html

I think that django can help in attract Windows/IIS developers.

Some discussion:

http://groups.google.com/group/django-users/browse_thread/thread/530e823938919feb

Some starting points:

FastCGI for IIS

http://www.caraveo.com/fastcgi/

Some backgroun in how RoR guys make it:

http://made-of-stone.blogspot.com/2006/01/rails-on-iis-revisited.html

And pretty simple rewrite solution for IIS with ASP.NET enable:

http://urlrewriter.net/index.php/using/installation/windows-server-2003

From the gogle groups was suggesting:

1- Ignore IIS. Go to Apache/etc...

A good advice if is currently impossible go for IIS. But is bad from the point of view of the developer/company/customer that is considering python/django for development. People hate change things ;)

2- Proxy IIS to Apache/etc..

Good for a intranet/dedicated server/vps setup... any hint?

3- Figure out how match the RoR solution or leverage the others ways to deploy IIS

Attachments (1)

pyisapie.py (5.7 KB) - added by pjs 8 years ago.
IIS ISAPI handler for django.core.handlers

Download all attachments as: .zip

Change History (30)

comment:1 Changed 9 years ago by José Arturo Cano

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....

comment:2 Changed 9 years ago by mtredinnick

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.

comment:3 Changed 9 years ago by pyisapie@…

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

comment:4 Changed 9 years ago by casey

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.

comment:5 Changed 9 years ago by alang@…

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

comment:6 Changed 9 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

comment:7 Changed 9 years ago by Michael Radziej <mir@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:8 Changed 8 years ago by mtredinnick

  • Needs documentation set
  • Triage Stage changed from Design decision needed to Accepted
  • Version changed from magic-removal to SVN

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

comment:9 Changed 8 years ago by torrycn@…

comment:10 Changed 8 years ago by mamcx

  • Keywords iis fastcgi added

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.

comment:11 Changed 8 years ago by jacob

  • Triage Stage changed from Accepted to Someday/Maybe

comment:12 Changed 8 years ago by vcc@…

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

comment:13 Changed 8 years ago by pjs

  • Component changed from Documentation to Core framework
  • Has patch set
  • Needs documentation unset
  • Triage Stage changed from Someday/Maybe to Ready for checkin

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.

comment:14 Changed 8 years ago by mtredinnick

  • Component changed from Core framework to Documentation
  • Triage Stage changed from Ready for checkin to Someday/Maybe

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

Changed 8 years ago by pjs

IIS ISAPI handler for django.core.handlers

comment:15 follow-up: Changed 8 years ago by Chaiwat Suttipongsakul <cwt@…>

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.

comment:16 in reply to: ↑ 15 ; follow-up: Changed 8 years ago by 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.

comment:17 Changed 8 years ago by pjs

  • Component changed from Documentation to Core framework
  • Keywords isapi added
  • Triage Stage changed from Someday/Maybe to Ready for checkin

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.

comment:18 Changed 8 years ago by jacob

  • Triage Stage changed from Ready for checkin to Design decision needed

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.

comment:19 in reply to: ↑ 16 ; follow-up: Changed 8 years ago by Chaiwat Suttipongsakul <cwt@…>

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'.

comment:20 in reply to: ↑ 19 Changed 8 years ago by anonymous

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.

comment:21 Changed 7 years ago by mrtwice99

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.

comment:22 Changed 6 years ago by anonymous

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.

comment:23 Changed 5 years ago by phoebebright

I'd like to nudge this one. I'm trying to introduce django as an option into public sector organisations and having to install apache is a big blocker. I've been delighted at how easy it is to access MSSQL data from django and think there is a real opportunity here if it would only run happily under IIS. I guess the problem is that it is neither a django problem nor an IIS problem so what currently needs to be done to make this an easy option?

comment:24 Changed 5 years ago by russellm

  • Triage Stage changed from Design decision needed to Someday/Maybe

What needs to be done? Someone needs to write the code.

Support for MSSQL isn't part of Django's core; it's part of an external project that utilizes an interface that Django provides.

Django also provides an interface for deployment, although it's not as mature or formalized as the database interface. Someone just needs to write the code to allow IIS to exploit this interface.

If it turns out that modifications are required to Django's interface in order to make this happen, I'm happy to accomodate those changes.

comment:25 Changed 5 years ago by sitbon

It does run happily under IIS, and faster than most other servers. You just need to look around for different configuration options. Currently there is isapi-wsgi and PyISAPIe, both with minimal documentation but the latter is much more flexible (disclaimer: I am biased, I am the author of the latter :).

Django devs have already stated to me that they have no intention for windows/IIS support so you are going to be best off using any WSGI-type interface to IIS. FastCGI is yet another option IIRC.

So, besides having to do a little bit of configuration, I don't really see what the issue is...

(BTW, your Trac login doesn't work with Chrome.)

comment:26 Changed 5 years ago by russellm

@sitbon - I *am* a Django core developer.

There is a difference between adding IIS support to trunk, and making any changes to trunk that are necessary in order to support IIS. We're happy to do the latter, and that's what I described in my last post. The former isn't an attractive option simply because IIS isn't something that most of the core team is in a position to test.

Also, I just logged into Trac using Chrome without any problems. I don't doubt you're having difficulties, but there's more to the problem than "using Chrome".

comment:27 Changed 5 years ago by sitbon

@russellm - yes, the problem wasn't consistently with Chrome for me either, sorry for making a fuss.


"There is a difference between adding IIS support to trunk, and making any changes to trunk that are necessary in order to support IIS"


In this department, there isn't a lot that *needs* to be done, it's just a matter of how and how much. I think part of the hindrance here in making Django/IIS a great or popular combo is (1) Django devs working mostly in non-IIS environments so their efforts are elsewhere (which is understandable), and (2) IIS-Python devs (such as myself) haven't gone out of their way to make any firm support for Django.


I've done my best with WSGI, os.environ hooks, and explaining how app pools work to help people use Django, and also made the mistake of proposing a core handler a couple years ago (the file attached above). I've only been supporting the PyISAPIe core since then, so hopefully anyone who believes there's more to be done can find it useful .


So, as far as making changes, I think all people really want in IIS is easy ways to do multiple instances (so, not relying on process-level environ variables), or at least that's what I get asked about most on the IIS side of things. However, I don't think it's necessary to be discussed here.

comment:28 Changed 4 years ago by lrekucki

  • Resolution set to needsinfo
  • Severity changed from minor to Normal
  • Status changed from new to closed
  • Type changed from enhancement to Uncategorized

I read the discussion few times now and it's still not clear to me what is being proposed. What changes need to be made?

comment:29 Changed 4 years ago by SmileyChris

  • Type changed from Uncategorized to New feature
Note: See TracTickets for help on using tickets.
Back to Top