Réécriture d’URL IIS et routage ASP.NET
Avec la publication du module Réécriture d’URL pour IIS et l’inclusion du routage ASP.NET dans le .NET Framework 4, il y a eu beaucoup de questions de la part des développeurs ASP.NET sur la relation entre ces deux fonctionnalités et quand vous devez utiliser l’une ou l’autre. Ce document décrit les différences entre ces deux technologies et fournit des conseils aux développeurs web sur le moment où utiliser la réécriture d’URL IIS et quand utiliser le routage ASP.NET.
Du point de vue général, il semble que ces technologies fournissent des fonctionnalités très similaires : les deux permettent à vos applications web d’avoir des URL conviviales pour les utilisateurs et les moteurs de recherche. Toutefois, il existe des différences fondamentales entre ces deux technologies qui sont importantes à comprendre pour prendre la bonne décision sur ce qu’il faut utiliser pour votre application web. Pour vous aider à comprendre ces différences, nous allons d’abord expliquer comment la réécriture d’URL IIS et le travail de routage ASP.NET.
Réécriture d’URL IIS
L’idée de base de la réécriture d’URL n’est pas un nouveau concept. Elle a été introduite dans le serveur web Apache il y a environ dix ans. Depuis lors, elle s’est avérée un outil très utile pour les administrateurs de serveur web et les développeurs web. De nombreuses applications populaires hébergées sur Apache s’appuient désormais sur la réécriture d’URL pour activer la prise en charge des URL « propres ».
Le concept de réécriture d’URL est simple. Lorsqu’un client envoie une requête au serveur web pour une URL particulière, le module Réécriture d’URL analyse l’URL demandée et le remplace par une URL différente sur le même serveur. Le module Réécriture d’URL s’exécute tôt dans le pipeline de traitement des demandes, en modifiant l’URL demandée avant que le serveur web décide quel gestionnaire utiliser pour traiter la requête. Le gestionnaire, qui est choisi en fonction de l’URL réécrite, traite la requête et génère une réponse renvoyée au navigateur web. Le client demandeur ne voit jamais l’URL réécrite ; en ce qui concerne le client, il a reçu une réponse de l’URL d’origine.
En termes d’architecture IIS, ce processus est représenté par le diagramme suivant :
Le module Réécriture d’URL est un module de code natif qui se connecte au pipeline de traitement des demandes aux stades Prédémarrer la requête ou Démarrer la requête, puis évalue le chemin d’accès d’URL demandé à l’aide d’un ensemble de règles de réécriture. Chaque règle de réécriture analyse le chemin d’URL et, si toutes les conditions de règle sont remplies, modifie le chemin d’origine en un nouveau chemin d’accès. Une fois que toutes les règles ont été évaluées, le module Réécriture d’URL produit un chemin d’URL final utilisé pour la requête via le reste du traitement du pipeline IIS. Cela signifie que la sélection du gestionnaire dans le pipeline IIS est effectuée en fonction de l’URL réécrite produite par le module Réécriture d’URL.
Routage ASP.NET
Le routage ASP.NET est un mécanisme de répartition des requêtes qui permet aux développeurs d’associer une URL spécifique à un gestionnaire capable de traiter les requêtes adressées à cette URL. Cette association est effectuée en inscrivant les « itinéraires » qui définissent le gestionnaire à appeler pour un chemin d’URL particulier. Lorsqu’une requête est adressée à un routage ASP.NET de serveur web recherche le chemin d’URL demandé dans la liste des itinéraires inscrits. Si l’itinéraire est trouvé, le gestionnaire correspondant de cet itinéraire est appelé pour traiter cette requête.
En termes d’architecture IIS et ASP.NET, ce processus est représenté par le diagramme suivant :
Le routage ASP.NET est implémenté en tant que module de code managé qui se connecte au pipeline de traitement des requêtes IIS à l’étape Résoudre le cache (événement PostResolveRequestCache) et à l’étape Gestionnaire de mappage (événement PostMapRequestHandler). Le routage ASP.NET est configuré pour s’exécuter pour toutes les requêtes adressées à l’application web.
Pendant l’événement PostResolveRequestCache, le module examine une table de routage (collection d’objets d’itinéraire) pour un itinéraire qui correspond au chemin d’URL demandé. Si une correspondance est trouvée, le module obtient une référence au gestionnaire qui correspond à cet itinéraire et enregistre la référence dans le contexte HTTP actuel. Un gestionnaire peut être n’importe quel objet .NET Framework qui implémente l’interface System.Web.IHttpHandler. Si aucun itinéraire n’est trouvé, le module ne fait rien, et l’URL passe et est traitée normalement (généralement en la faisant correspondre à un fichier sur le disque).
Pendant l’événement PostMapRequestHandler, le module vérifie si le contexte HTTP contient des informations sur un gestionnaire. Si c’est le cas, le routage ASP.NET utilise les informations pour définir la propriété Gestionnaire du contexte HTTP actuel. Cela garantit que pendant l’étape d’exécution du gestionnaire, IIS exécute le gestionnaire sélectionné par le module de routage. Si ces informations ne sont pas définies, le module ne fait rien et l’URL passe pour permettre à IIS de sélectionner un gestionnaire.
Différences entre la réécriture d’URL IIS et le routage ASP.NET
En fonction de l’explication ci-dessus, voici les principales différences conceptuelles suivantes entre la réécriture d’URL IIS et le routage ASP.NET :
- La réécriture d’URL est utilisée pour manipuler les chemins d’URL avant que la requête ne soit gérée par le serveur web. Le module Réécriture d’URL ne sait pas quel gestionnaire traitera éventuellement l’URL réécrite. En outre, le gestionnaire de requêtes réel peut ne pas savoir que l’URL a été réécrite.
- Le routage ASP.NET est utilisé pour distribuer une requête à un gestionnaire en fonction du chemin d’URL demandé. Contrairement à la réécriture d’URL, le module de routage connaît les gestionnaires et sélectionne le gestionnaire qui doit générer une réponse pour l’URL demandée. Vous pouvez considérer le routage ASP.NET comme un mécanisme de mappage de gestionnaires avancé.
En plus de ces différences conceptuelles, il existe les différences fonctionnelles suivantes entre la réécriture d’URL IIS et le routage ASP.NET :
- Vous pouvez utiliser le module Réécriture d’URL IIS avec n’importe quel type d’application web, qui inclut ASP.NET, PHP, ASP et les fichiers statiques. Vous ne pouvez utiliser le routage ASP.NET qu’avec les applications web basées sur .NET Framework.
- Le module Réécriture d’URL IIS fonctionne de la même façon que le mode pipeline IIS intégré ou classique soit utilisé pour le pool d’applications. Pour le routage ASP.NET, il est préférable d’utiliser le mode pipeline intégré. Le routage ASP.NET peut fonctionner en mode classique, mais dans ce cas, les URL d’application doivent inclure des extensions de nom de fichier ou l’application doit être configurée pour utiliser le mappage de gestionnaires « * » dans IIS.
- Le module Réécriture d’URL IIS peut prendre des décisions de réécriture en fonction des noms de domaine, des en-têtes HTTP et des variables de serveur. Par défaut, le routage ASP.NET fonctionne uniquement avec les chemins d’URL et avec l’en-tête HTTP-Method.
- Outre la réécriture, le module Réécriture d’URL peut effectuer une redirection HTTP, émettre des codes d’état personnalisés et abandonner les requêtes. Le routage ASP.NET n’effectue pas ces tâches.
- Le module Réécriture d’URL n’est pas extensible dans sa version actuelle. Le routage ASP.NET est entièrement extensible et personnalisable.
Quelle option devez-vous utiliser ?
Que signifient toutes ces informations si vous avez besoin de choisir une technologie pour activer des URL propres pour vos applications web ? Dans cette section, nous expliquons comment faire ce choix.
Si votre application web est conçue à partir de tout sauf ASP.NET, utilisez le module Réécriture d’URL IIS. Sinon, les règles sont les suivantes :
- Si vous développez une nouvelle application web ASP.NET qui utilise les technologies ASP.NET MVC ou ASP.NET Dynamic Data, utilisez le routage ASP.NET. Votre application bénéficie de la prise en charge native des URL propres, notamment la génération d’URL propres pour les liens dans vos pages web. Notez que le routage ASP.NET ne prend pas encore en charge les applications Web Forms standard, bien qu’il existe des projets de prise en charge pour le futur.
- Si vous disposez déjà d’une application web ASP.NET héritée et que vous ne souhaitez pas la modifier, utilisez le module Réécriture d’URL. Le module Réécriture d’URL vous permet de traduire les URL conviviales pour les moteurs de recherche dans un format que votre application utilise actuellement. En outre, il vous permet de créer des règles de redirection qui peuvent être utilisées pour rediriger les analyseurs du moteur de recherche vers des URL propres.
Toutefois, dans la pratique, le choix n’a pas besoin d’être exclusif. Les technologies peuvent être utilisées ensemble et peuvent se compléter mutuellement. Dans les sections suivantes, nous décrivons certains scénarios dans lesquels vous pouvez utiliser le routage ASP.NET et la réécriture d’URL IIS.
Application d’URL canoniques pour votre application.
Vous devez forcer l’utilisation de http://www.mysite.com/home/about lieu de http://mysite.com/Home/About. Lorsqu’un client web demande une URL qui n’est pas conforme au format souhaité, le client est redirigé vers une URL canonique. Dans ce scénario, vous pouvez utiliser le module Réécriture d’URL pour appliquer des URL canoniques et effectuer la redirection, et utiliser le routage ASP.NET pour sélectionner un gestionnaire qui traiterait le chemin d’URL demandé.
L’exemple suivant montre une règle de réécriture d’URL que vous pouvez utiliser pour ce scénario :
<rewrite>
<rules>
<rule name="Enforce canonical hostname" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
</conditions>
<action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
Diffusion de contenu statique à partir d’un autre site ou serveur.
Votre application web est déployée sur plusieurs serveurs de telle sorte que le contenu web dynamique se trouve sur un site ou un serveur et que tout le contenu statique se trouve sur un autre site ou serveur. Vous pouvez utiliser le module Réécriture d’URL avec le module IIS Application Request Routing pour transférer toutes les demandes de fichiers statiques vers un autre serveur, tout en servant toutes les requêtes de pages web dynamiques à partir du serveur actuel. De cette façon, le routage ASP.NET est utilisé uniquement pour le contenu web dynamique et n’évalue aucune URL pour le contenu statique.
L’exemple suivant montre une règle de réécriture d’URL que vous pouvez utiliser pour ce scénario :
<rewrite>
<rules>
<rule name="Forward to static file server">
<match url="^.+\.(?:jpg|bmp|gif)$" />
<action type="Rewrite" url="http://static_file_server/{R:0}" />
</rule>
</rules>
</rewrite>
Gestion de contenu statique.
Lorsque vos fichiers ou dossiers statiques sont déplacés vers un nouvel emplacement, vous pouvez toujours prendre en charge les anciennes URL pour des raisons de compatibilité descendante. En fait, vous ne souhaiterez peut-être pas que les visiteurs du site web sachent que les fichiers ou dossiers ont été déplacés. Dans ce cas, vous pouvez utiliser le module Réécriture d’URL pour réécrire les chemins d’accès aux fichiers statiques, tandis que toutes les URL de vos pages web dynamiques ASP.NET sont gérées par le module de routage.
L’exemple suivant montre une règle de réécriture d’URL que vous pouvez utiliser pour ce scénario :
<rewrite>
<rules>
<rule name="Rewrite to new folder">
<match url="^Images/(.+)$" />
<action type="Rewrite" url="NewImages/{R:1}" />
</rule>
</rules>
</rewrite>
Blocage de la requête.
Vous pouvez utiliser le module Réécriture d’URL pour bloquer certaines requêtes en fonction de différents critères. Par exemple, vous pouvez empêcher certains analyseurs de site d’accéder à des chemins d’URL spécifiques sur votre site web. De cette façon, les requêtes interdites n’arrivent même pas au routeur ASP.NET, ce qui réduit la charge sur votre serveur web.
L’exemple suivant montre une règle de réécriture d’URL que vous pouvez utiliser pour bloquer les analyseurs de site indésirables. Notez que les requêtes sont bloquées pour un chemin d’URL particulier en fonction de l’en-tête HTTP de l’agent utilisateur ou de l’adresse IP du client :
<rewrite>
<rules>
<rule name="Block SomeRobot" stopProcessing="true">
<match url="^folder1/folder2" />
<conditions logicalGrouping="MatchAny">
<add input="{USER_AGENT}" pattern="SomeRobot" />
<add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
</rewrite>
Directions futures
Même si la réécriture d’URL IIS et le routage ASP.NET ont un chevauchement fonctionnel, ils traitent des scénarios uniques à chaque technologie. En raison de cela, ces deux technologies continueront d’exister et d’évoluer en tant que composants indépendants dans IIS, avec le potentiel d’intégration plus étroite entre elles. Par exemple, le routage ASP.NET peut tirer parti de certains des outils enrichis fournis avec le module Réécriture d’URL. Le module Réécriture d’URL peut être mieux intégré à ASP.NET en termes de fourniture d’extensibilité pour la personnalisation de la logique de réécriture d’URL.
Conclusion
Vous pouvez utiliser la réécriture d’URL IIS ou le routage ASP.NET pour implémenter des scénarios de manipulation d’URL pour votre application web. Le routage ASP.NET est une solution optimisée pour ASP.NET, il peut donc être préférable pour les développeurs web qui conçoivent leurs applications ASP.NET à partir de la base et souhaitent avoir une structure d’URL propre. La réécriture d’URL IIS est un mécanisme générique de manipulation d’URL qui traite une multitude de scénarios. En particulier, les développeurs web et les administrateurs de serveur/site web peuvent l’utiliser pour activer les URL propres pour les applications web existantes sans modifier le code de l’application.
Documents associés
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour