Page d'accueil>Tutoriel de programmation réseau>Tutoriel ASP.NET

URL Rewrite (2) : utilisation de composants pour la réécriture d'URL

Auteur：Eve Cole Date de mise à jour：2009-06-29 23:46:44
Le principe du composant URL Rewrite au niveau asp.net est très simple. En fait, il écoute simplement l'événement BeginRequest et détermine l'URL cible en fonction de la configuration. Dans les projets auxquels j'ai participé auparavant, j'ai constaté que la fréquence d'utilisation d'URLRewriter comme composant de réécriture d'URL est très élevée, je pense que cela peut être dû au fait qu'il s'agit d'un élément fourni par Microsoft.
Si vous souhaitez utiliser URLRewriter, la première étape naturelle consiste à configurer un HttpModule dans web.config :

<httpModules>
< ajouter
nom = " ModuleRewriter "
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModules>

Il est ensuite temps de configurer (Remarque : il est fortement recommandé d'utiliser l'attribut configPath pour extraire la configuration dans des fichiers supplémentaires pour une gestion plus facile) :
<configSections>
< rubrique
nom = " RéécrivainConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RéécrivainConfig>

<Règles>

<RéécrivainRègle>

< Recherche > ~/tag/([w]+)/ </ Recherche >

< SendTo > ~/Tags.aspx?Tag=$1 </ SendTo >

</RewriterRule>

</ Règles >
</RewriterConfig>

Les expressions régulières sont une chose étonnante, elles peuvent correspondre et capturer. Dans l'exemple ci-dessus, nous déplaçons "/tag/xxx" qui répond aux conditions LookFor vers la page Tags.aspx et utilisons xxx comme valeur de l'élément Tag QueryString, afin que nous puissions transmettre HttpContext.Request.QueryString dans le code. . ["Tag"] pour obtenir la valeur.
La fonctionnalité d' URLRewriter est suffisante pour la plupart des applications, mais je ne l'ai toujours pas aimée. Mais si vous devez me demander pourquoi je n'aime pas ça, je ne peux pas vous dire le vilain Yinmao. C'est peut-être juste un problème avec cette méthode de configuration. Lors de l'utilisation d'URL Rewriter, la section de configuration est souvent très longue. Chaque élément de configuration nécessite un total de 4 lignes de code de <RewriterRule> à </RewriterRule>. Un projet à petite échelle peut facilement avoir des centaines de lignes de configuration. "C'est trop XML", ai-je pensé, pourquoi ne pas utiliser l'attribut XML ? Cela réduit chaque élément de configuration à 1 ligne - mais c'est une digression.
Donc, si je souhaite actuellement faire de la réécriture d'URL, j'utilise souvent le composant open source UrlRewriter.NET produit par Intelligencia . Bien que ce nom soit très similaire au précédent, sa fonctionnalité est de loin supérieure à l’ancien. Ce composant est relativement proche d'URLRewriter en utilisation (en fait, il semble que tous les composants URL Rewrite soient similaires. Il suffit de configurer :

<configSections>
< rubrique
nom = " réécrivain "

 type = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Intelligencia.UrlRewriter " />
</configSections>


<réécrivain>

< réécrire
url = " ^/Utilisateur/(d+)$ "
à = " ~/User.aspx?id=$1 "
traitement = " arrêter " />

< réécrire
url = " ^/Utilisateur/(w+)$ "
à = " ~/User.aspx?name=$1 "
traitement = " arrêter " />
</réécrivain>


< système.web >

<httpModules>

< ajouter
nom = " UrlRewriter "

 type = " Intelligencia.UrlRewriter.RewriterHttpModule,

Intelligencia.UrlRewriter " />

</httpModules>
< /system.web >
Regardons principalement l'élément de configuration <rewriter /> des règles de réécriture. Différent d'URLRewriter, UrlRewriter.NET utilise ma méthode préférée d'un nœud par règle, ce qui simplifie grandement les règles de réécriture de l'ensemble du projet. Mais que signifie traitement="stop" ? Il s'agit de la façon dont UrlRewriter.NET gère les règles de réécriture. Lorsque UrlRewriter.NET trouve une règle de réécriture correspondante, il ne s'arrêtera pas là, mais continuera à rechercher d'autres correspondances. La dernière règle de réécriture pouvant correspondre à la requête actuelle prendra finalement effet. Si nous avons besoin qu'UrlRewriter.NET prenne effet après avoir trouvé une correspondance, nous devons définir l'attribut de traitement pour qu'il s'arrête. Par exemple, dans la configuration ci-dessus, si « /Utilisateur/ » est suivi d'un nombre, l'ID utilisateur sera utilisé pour la recherche, sinon le nom d'utilisateur actuellement fourni sera pris en compte.
Si UrlRewriter.NET est simplement plus simple en configuration, il n'a aucun avantage par rapport à URLRewriter. Mais les capacités d'UrlRewriter.NET vont bien au-delà de cela. Ce que nous venons d'utiliser n'est en fait qu'une des actions qu'il propose. De plus, il fournit également de nombreuses actions :

  • if,
  • à moins que
  • la réécriture
  • redirige
  • setstatus
  • interdit
  • disparu
  • non autorisé
  • introuvable
  • non implémenté
  • addheader
  • setcookie
  • setproperty
L'action seule ne suffit pas. UrlRewriter.NET fournit également la condition, la transformation, le document par défaut, l'analyseur, le gestionnaire d'erreurs, l'enregistreur et d'autres fonctions, et peut transmettre. Expression pour « représenter » une logique complexe. Ce n'est pas de la configuration, c'est simplement de la programmation ! C'est vrai, UrlRewriter.NET peut être utilisé pour exprimer une logique requête-réponse via la configuration, ce qui nous apporte sans aucun doute une grande commodité. Il m'est impossible d'expliquer tous les aspects d'UrlRewriter.NET en détail ici. Les amis intéressés peuvent examiner de plus près la référence fournie par son site officiel. "Si vous avez des composants comme celui-ci, que demander de plus ?" Cependant, je souhaite quand même recommander un autre composant ici. Car dans certains cas particuliers, UrlRewriter.NET ne peut pas répondre à nos exigences. Euh ? Ne peut-il pas s'étendre tout seul ? C'est vrai, mais - mettons d'abord cela de côté, et j'expliquerai ce problème dans le dernier article de cette série. UrlRewriter.NET fournit un réécrivain d'URL au niveau ASP.NET. Si vous souhaitez effectuer une réécriture d'URL au niveau IIS, vous devez utiliser d'autres méthodes. ISAPI Rewrite est un composant bien connu pour la réécriture d'URL au niveau IIS. Malheureusement, il s'agit d'un composant commercial et nous devons l'acheter en dollars américains. Par conséquent, je recommande ici un autre produit open source : IIRF (Ionic's Isapi Rewrite Filter) .
Étant donné que la réécriture d'URL est effectuée au niveau IIS, la méthode de configuration d'IIRF est différente de celle d'UrlRewriter.NET. Si vous souhaitez utiliser IIRF, vous devez ajouter IsapiRewrite4.dll à la liste des filtres ISAPI du site Web :
IIRF est configuré via le fichier ini et IsapiRewrite4.dll peuvent être placés dans le même répertoire :
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
La règle de réécriture de l'IIRF est "RewriteRule <url-pattern> <destination> [<modifiers>]". Il n'y a pas de limite sur le nombre d'espaces entre chaque partie, mais il doit s'agir d'un espace, pas d'autres caractères d'espacement tels que Tab. . Inutile de dire que "modèle d'url" et "destination", la clé réside dans le modificateur. Il existe de nombreux modificateurs pour IIRF. Ici, je ne présenterai que les deux utilisés ci-dessus. "I" signifie que la correspondance est indépendante de la casse. La fonction de "L" est similaire à traitement = "stop" dans UrlRewriter.NET et IIRF prendra effet immédiatement lorsque la correspondance sera trouvée et ne poursuivra pas la recherche.
Bien que IIRF soit un composant open source, ses fonctions restent relativement puissantes. Surtout après avoir combiné RewriteCond (Rewrite Condition), des règles de réécriture plus complexes peuvent être implémentées. Par exemple, la configuration suivante réécrit la requête du répertoire racine contenant le mot Googlebot dans UserAgent vers une ressource spécifique :
RéécritureCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
Enfin, jetons un coup d'œil à la différence entre les deux composants Rewrite. Évidemment, la plus grande différence est qu'il s'agit de réécritures à des niveaux différents. Les deux diagrammes schématiques ci-dessous décrivent comment, dans les deux cas, ils modifient le "/User/jeffz" qui aurait dû obtenir le résultat "404 Resource Not Found". "/Utilisateur/nom=jeffz".
Le premier est la réécriture d'URL par UrlRewriter.NET au niveau ASP.NET :
Vient ensuite la réécriture d’URL de l’IIRF au niveau IIS :

Avec ces deux composants, je pense que nous n'avons plus besoin de rien d'autre pour implémenter la réécriture d'URL.