Si vous êtes obligé d'utiliser IIS, utilisez PyISAPIe au lieu de CGI si vous le pouvez. Les instructions et les liens pour PyISAPIe sont ci-dessous. Votre hébergeur en saura beaucoup plus sur les extensions ISAPI s'il gère IIS que sur Python, et il n'a pas besoin d'en savoir beaucoup sur Python avec PyISAPIe.
UNE BIEN MEILLEURE FAÇON DE LE FAIRE EST D'UTILISER PyISAPIe, UNE EXTENSION ISAPI . PyISAPIe est beaucoup, beaucoup plus rapide que CGI sur IIS7. Ce qu'il fait est similaire à mod_python sur Apache. La page d'accueil du projet PyISAPIe contient des instructions pour configurer Django avec WSGI sur PyISAPIe. Cela vous permettra d'atteindre des performances raisonnables pour un site Web public ou à fort trafic.
La mise en place de Django dans un environnement IIS+Python via CGI va être horriblement lente pour toute utilisation en production. Vous ne devriez jamais utiliser cette méthode pour un site Web sur lequel vous prévoyez de traiter plus d'une poignée de demandes par minute. Cela vous limite aussi sévèrement dans ce que vous pouvez mettre en mémoire cache dans le cadre de mise en cache de Django, puisque le processus de l'application Django est redémarré à chaque nouvelle requête.
Dans un serveur web sain comme Apache, lighttpd, etc., avec mod_python, l'interpréteur Python qui exécute le processus Django reste en mémoire et est initialisé avec chaque nouveau thread de travail Apache qui traite de nombreuses requêtes au fil du temps. Cela signifie que Python + Django ne sont pas quittés et redémarrés pour chaque nouvelle requête. Dans une configuration FastCGI, le serveur Web (Apache ou lighttpd par exemple) crée un socket (domaine UNIX ou TCP) par lequel il communique avec une application FastCGI (votre application Web Django) via le protocole FastCGI. Idem pour les configurations de proxy HTTP (ils parlent HTTP au lieu de FastCGI). Dans un environnement CGI, c'est l'interpréteur Python qui est appelé et qui exécute l'application Django, complètement à nouveau pour chaque requête, de sorte que l'application ne peut pas conserver en mémoire l'état des requêtes et ne peut pas mettre correctement en cache autre chose que dans une base de données.
Trêve de plaisanterie, si vous devez utiliser IIS+CGI+Django, voici comment accomplir cette horrible chose : Utilisez le code suivant pour créer votre propre CGI script qui exécute votre application Django (il fait la traduction entre CGI et WSGI). Vous devrez modifier un peu le script pour qu'il pointe vers votre application et votre code Django. C'est le script CGI auquel vous devrez passer les requêtes. Ensuite, vous devez transmettre/réécrire toutes les demandes à votre CGI script...
Sous IIS6, vous aurez besoin d'un équivalent de mod_rewrite comme IISRewrite, qui, je crois, n'est pas gratuit et est fermé. Sous IIS7, Microsoft a finalement inclus un module de réécriture d'URL. Sa documentation se trouve à l'adresse suivante aquí . Les instructions pour créer des règles de réécriture dans IIS7 sont les suivantes aquí . Vous voudrez faire suivre tout ce qui se trouve à l'URL de base cible pour être traité par votre CGI script.
