août 02 2010

[ASP.NET 4] Optimisation du référencement partie 2 : Routage ou réécriture d'URL ?

Category: ASP.NET | IIS 7.0 | ASP.NET 4Nicolas Esprit @ 15:12

Suite de la série d'articles sur la Search Engine Optimization. Le premier, ayant pour sujet le module IIS Search Engine Optimization Toolkit est consultable ici.

Avant d'entrer dans le vif du sujet et de décrire des bouts de code illustrant le routage d'URL (URL Routing), il est nécessaire de revenir sur la définition et les différences entre les deux concepts que sont le routage d'URL et la réécriture d'URL (URL Rewriting).

En effet avec la démocratisation du module de réécriture d'URL d'IIS7 et l'inclusion du routage dans la version 4.0 d'ASP.NET, il n'est pas évident pour un développeur de savoir comment les deux sont reliés et surtout quel concept utiliser. Nous allons donc nous attarder ici à décrire les différences entre ces deux technologies et fournir des conseils pour les développeurs Web afin de savoir quand utiliser la réécriture d'URL IIS et quand utiliser le routage ASP.NET.

D'un point de vue conceptuel, il semble que ces technologies offrent des fonctionnalités très similaires (c'est-à-dire à la fois permettre à vos applications Web d'utiliser des URL conviviales et intuitives pour l'utilisateur et de pratiquer la Search Engine Optimization, c'est-à-dire mettre en place des optimisations pour les moteurs de recherche). Toutefois, il existe des différences fondamentales entre ces deux technologies qui sont importantes afin de savoir laquelle vous devez utiliser pour votre application Web. Pour vous aider à comprendre ces différences, nous allons d'abord expliquer comment celles-ci fonctionnent. Note : les explications qui suivent nécessitent un minimum de compréhension sur les HttpHandlers et les HttpModules.

Réécriture d'URL avec IIS 7

Le module de réécriture d'URL pour IIS 7.0 est un outil Microsoft que vous pouvez télécharger à partir du site IIS. net/extensions/URLRewrite. Cet outil peut effectuer toutes les tâches de canonisation d'URL à votre place, sans avoir besoin de code. Il gère la normalisation des en-têtes d'hôte, la mise en minuscules et d'autres opérations (telles que celles décrites sur ce blog). L'outil peut également vous aider à réparer les liens rompus en les réécrivant ou en les redirigeant à l'aide d'une carte, ce qui vous évite d'avoir à modifier votre application ou votre code HTML. Voir également ce blog.

Le module de réécriture d'URL peut également créer des URL descriptives pour toutes les versions d'ASP.NET et ce, de façon beaucoup plus performante que toute autre option existante, y compris le routage ASP.NET, car l'outil utilise une mise en cache en mode noyau.

La réécriture d'URL n'est pas un concept nouveau, il a été introduit dans le serveur Web Apache il y a une dizaine d'années. Depuis lors, il s'est avéré être un outil très utile pour les administrateurs de serveurs Web et les développeurs Web.

La notion de réécriture d'URL est simple. Quand un client envoie une requête vers le serveur Web pour une URL donnée, le module de réécriture d'URL analyse l'URL demandée et la transforme en une URL différente sur le même serveur. Le module de réécriture d'URL fonctionne au début du pipeline de traitement des requêtes, modifiant ainsi l'URL demandée avant que le serveur Web décide quel Handler utiliser pour traiter la demande. Le Handler, choisi en fonction de l'URL réécrite, traite la demande et génère une réponse qui est renvoyée vers le navigateur Web. L'utilisateur, autrement dit l'internaute, ne verra jamais l'URL réécrite. Il a simplement reçu la réponse à sa requête d'origine dont l'URL n'a pas changé.

Du point de vue de l'architecture de IIS 7, le processus peut être décrit selon le schéma suivant :

 

Le module de réécriture d'URL est un module de code natif qui se branche dans le pipeline de traitement de la demande à l'étape Pre-begin Request ou Begin Request, puis évalue les chemins d'URL demandés l'aide d'un ensemble de règles de réécriture. Chaque règle analyse les URL et, si toutes les conditions de la règle sont remplies, une nouvelle URL est utilisée (un peu à l'image d'une expression régulière appliquée à une chaîne de caractères). Une fois toutes les règles évaluées (et pas nécessairement appliquées), le module de réécriture d'URL produit une URL finale qui est utilisée pour la demande jusqu'à la fin du traitement IIS. Cela signifie que la sélection du Handler dans le pipeline IIS est basée sur l'URL produite par le module de réécriture d'URL, donc en interne côté serveur.

 

Routage d'URL avec ASP.NET 4.0

Le routage ASP.NET est un mécanisme de demande de réexpédition qui permet aux développeurs d'associer une URL particulière avec un Handler qui peut traiter les demandes faites à cette URL. Cette association se fait par l'enregistrement des "routes" qui définissent quel Handler invoquer pour un chemin d'URL donné. Lorsqu'une demande est adressée à un serveur Web, le routage ASP.NET compare le chemin URL demandé dans la liste des routes enregistrées. Si la route est trouvée, alors le Handler correspondant est appelé pour traiter cette demande.

Le schéma suivant illustre le processus du traitement de la requête avec le routage ASP.NET :

 

Le routage ASP.NET est implémenté comme un module qui se branche sur la requête de traitement du pipeline IIS à l'étape Resolve Cache (évènement PostResolveRequestCache) et à l'étape Map Handler (évènement PostMapRequestHandler). Il est configuré pour s'exécuter pour toutes les requêtes adressées à l'application Web.

Pendant l'événement PostResolveRequestCache, le module regarde dans une table de routage si une route correspond au chemin d'URL demandé. Si une correspondance est trouvée, le module obtient une référence du Handler qui correspond à cette route et enregistre la référence dans le cadre du contexte HTTP courant. Si aucune route n'est trouvée, le module ne fait rien et l'URL requêtée est normalement traitée (s'il n'y a pas de routage en place pour cette URL et on est ici dans le cas classique du chemin d'un fichier : http://www.monsite.com/Répertoire1/Répertoire2/MaPage.aspx).

Pendant l'événement PostMapRequestHandler, le module vérifie si le contexte HTTP contient une référence à un Handler. Si c'est le cas, le routage ASP.NET utilise ces renseignements pour assigner le Handler contexte HTTP courant. Cela garantit que, pendant la phase d'exécution, IIS va exécuter le Handler qui a été sélectionné par le module de routage. Si cette information n'est pas définie, alors le module de routage ne fait rien et IIS se charge seul de sélectionner un Handler pour l'URL requêtée.

 

Les différences entre la réécriture et le routage d'URL

En reprenant les explications précédentes, on peut déduire les différences conceptuelles entre la réécriture d'URL via le module IIS prévu à cet effet et le routage via le module de routage ASP.NET 4.0 :

  • la réécriture d'URL est utilisée pour manipuler les chemins d'URL avant que la requête soit traitée par le serveur Web. Le module de réécriture d'URL ne sait pas quel Handler finira par traiter l'URL réécrite. En outre, le Handler qui traitera la requête ne pourra pas savoir que l'URL a été réécrite ;
  • le routage ASP.NET est utilisé pour envoyer une requête à un Handler basé sur le chemin URL demandé. Au contraire de la réécriture d'URL, où le module de routage connaît les Handlers et sélectionne celui qui devra générer une réponse pour l'URL demandée. Vous pouvez considérer le routage ASP.NET comme un mécanisme avancé de mapping de Handler.

 

En plus de ces différences conceptuelles, il existe les différences fonctionnelles suivantes entre le module de réécriture IIS et le module de routage ASP.NET :

  • le module réécriture d'URL IIS peut être utilisé avec tout type d'applications Web, donc en plus des applications ASP.NET : les sites en PHP, en ASP classique mais aussi les fichiers statiques. Tandis que le routage ASP.NET ne peut être utilisé qu'avec les applications Web basées sur le Framework .NET ;
  • le module de réécriture d'URL IIS fonctionne de la même manière, indépendamment du mode pipeline IIS utilisé pour l'AppPool : intégré ou classique. 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 l'URL requêtée doit inclure les extensions de fichiers ou bien l'application doit être configurée pour utiliser le mapping "*" dans IIS pour les Handlers ;
  • le module de réécriture d'URL IIS peut prendre des décisions concernant la réécriture des URL basées sur les noms de domaine, les en-têtes HTTP et les variables serveur. Par défaut, le routage ASP.NET ne fonctionne qu'avec les chemins d'URL ;
  • en plus de la réécriture, le module de réécriture d'URL peut effectuer des redirections HTTP, l'émission de codes de réponse personnalisés (au lieu d'un simple 404), ou encore abandonner la requête. Le routage ASP.NET ne peut exécuter ces tâches.
  • le module de réécriture d'URL n'est pas extensible dans sa version actuelle. Le routage ASP.NET est entièrement extensible et personnalisable.

 

Que choisir routage ou réécriture d'URL ?

Que déduire de toutes ces informations si vous avez besoin de choisir une technologie pour mettre en place des URL intuitives ou pratiquer la SEO ? L'équipe IIS de Microsoft recommandait encore il y a peu d'utiliser le module de réécriture d'URL si votre application était développée uniquement en ASP.NET Web Forms. Pour les autres technos ASP.NET, à savoir MVC et Dynamic Data, Microsoft recommandait, et c'est toujours d'actualité, d'utiliser le routage ASP.NET afin de bénéficier d'un support natif du routage des URL dans votre application.

Avec l'arrivée du routage dans les applications Web Forms ASP.NET 4.0, la donne a changé. Dans tous les cas, le choix ne doit pas être l'un ou l'autre. Ces deux technologies peuvent être utilisées ensemble et se complètent mutuellement.

Le troisième et dernier article de cette série se focalisant uniquement sur le routage d'URL, voici un ensemble de liens très pertinents sur la réécriture d'URL avec IIS :

Tags: , , , , , , , ,

Les commentaires sont clos