IIS 7.5, plusieurs pools d'applications et réécriture d'URL (403.18 – Interdit)

Existe-t-il un moyen de configurer IIS 7.5 pour effectuer des réécritures d'URL vers différents pools d'applications sur le même site sans avoir à provoquer une erreur 403.18?

Nous utilisons Helicon ISAPI Rewrite 3 sur IIS 6 et ça fonctionne comme un charme. L'«application» de niveau racine est exécutée sous son propre groupe d'applications, et sur IIS 6, nous n'avons aucun problème pour que l'URL réécrie de ce pool d'applications à l'un des quatre autres pools d'applications. Mais lorsque je copy les mêmes informations de configuration du server sur IIS 7.5, l'URL réécrit sur l'un des autres pools d'applications échoue avec une erreur "403.18 – Forbidden".

Le bit bizarre est que l'IIS 6 n'est pas (au less aussi loin que je peux le dire, en regardant la boîte de dialog de configuration du service du site) en cours d'exécution en mode d'émulation IIS 5, de sorte que les réécritures ne lancent pas 403.18 erreurs. Donc, quelque chose doit être différent … mais peu importe, je n'ai certainement pas réussi à le comprendre.

Btw, nous ne sums pas mariés à Helicon ISAPI Rewrite. S'il existe une autre façon de conserver nos règles de configuration de réécriture actuelles en utilisant un autre module ou méthode, je serais plus que content de l'utiliser.

    5 Solutions collect form web for “IIS 7.5, plusieurs pools d'applications et réécriture d'URL (403.18 – Interdit)”

    Dans IIS, vous ne pouvez pas simplement apather la request d'une application vers l'autre. Les applications sont isolées, c'est pourquoi vous obtenez 403 erreurs.

    Vous pouvez requestr des requêtes en utilisant soit ISAPI_Rewrite, Ape ou ARR. Peu importe, la request sera transmise à une autre application en utilisant la request HTTP locale de toute façon. Cette solution est assez stable, mais vous allez perdre des performances.

    La redirection n'est probablement pas une option ici, car elle générera deux requêtes sur le server de toute façon, mais comme la request sera générée par l'user, les performances de connection lente peuvent diminuer considérablement.

    Il n'est pas pris en charge par IIS7 pour le nouveau composant Microsoft Rewrite de Microsoft. Le même problème se produit.

    Je ne me souvenais pas qu'il était possible dans IIS6 de réécrire dans les pools d'applications. Vous faites une réécriture et non une redirection? Une redirection fonctionnera dans IIS7.

    Je requestrais à Helicon à http://www.isapirewrite.com. Ils répondent bien à leurs forums. Peut-être que les modules ISAPI vivent pleinement dans le process w3wp.exe maintenant et ne peuvent donc pas envoyer leur request à un autre pool d'applications.

    L'autre endroit pour poser la question serait à http://forums.iis.net/ . L'équipe de développement de IIS répond à certains messages et peut fournir des détails sur la raison pour laquelle, même si la fonctionnalité ISAPI Rewrite a changé lors du passage à IIS7.

    En effet, cela n'est pas possible avec la réécriture d'URL, mais si vous voulez vraiment le faire, vous pouvez utiliser ARR (Application Request Routing) en conjonction et cela fonctionnera, mais notez qu'il serait vraiment faire une nouvelle request complète, en d'autres termes, il fonctionnera comme un proxy délivrant une nouvelle requête HTTP à elle-même, pour cela il faut réécrire pour utiliser l'URL complète, y compris le nom de l'hôte et tous. Il s'agit d'une grosse surcharge, donc uniquement si elle est critique pour l'application.

    Bien sûr, comme l'a déjà mentionné Scott Forsyth, l'autre option consiste à utiliser une redirection.

    Nous utilisions également ISAPI Rewrite 3 sur IIS6, mais lorsque nous sums passés à IIS7.5, nous avons passé à Helicon APE et cela a bien fonctionné, puis réécrit. Vous pouvez utiliser datatables dans votre db pour réécrire les URL.

    C'est le sharepoint placard que j'ai trouvé qui s'approche de mod_rewrite pour IIS.

    http://www.iis.net/download/URLRewrite

    Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.