Dans les articles précédents, nous avons parlé de plusieurs aspects principaux de la réécriture d’URL. Dans le dernier article de cette série, nous aborderons certains détails et caractéristiques des différents niveaux de réécriture d'URL.
Théoriquement, la réécriture d’URL au niveau IIS écrite en C ou C++ offre des performances supérieures à la réécriture d’URL au niveau ASP.NET écrite en code managé. Mais je pense que la différence dans ce domaine est négligeable dans la plupart des cas, et il est presque impossible que cette performance devienne un goulot d'étranglement. Par conséquent, le niveau de réécriture d’URL choisi n’est généralement pas déterminé par les exigences de performances de votre application. Alors, quel niveau de réécriture d’URL faut-il utiliser ? Après avoir utilisé différents niveaux d’URL Rewrite, à quoi devons-nous prêter attention ? Je suis ici pour parler de mes opinions personnelles.
Bien que le composant actuel de réécriture d'URL puisse répondre à la plupart des applications en termes de fonctionnalités, à un moment donné, nous avons encore besoin de certaines fonctions spéciales. Par exemple, la réécriture d'URL basée sur le nom de domaine n'est pas facile à réaliser avec le composant actuel de réécriture d'URL. Le logiciel ISAPI Rewrite commercial peut actuellement prendre en charge cela. Malheureusement, les logiciels open source UrlRewriter.NET et IIRF n'ont pas de fonctions suffisantes à cet égard. Ils sont tous mis en correspondance en fonction du chemin de la requête par rapport au site, et le nom de domaine demandé ne peut pas être utilisé comme condition de correspondance. Cela nous oblige à étendre le composant URL Rewrite. Pour la plupart des développeurs .NET, le code managé est naturellement le premier choix pour le développement. À l'heure actuelle, il peut être nécessaire de choisir le composant de réécriture d'URL de niveau ASP.NET. Cependant, de nombreux exemples d'extensions peuvent être trouvés sur Internet, qu'il s'agisse de UrlRewriter.NET au niveau ASP.NET ou de IIRF au niveau IIS.
Mais en fait, si nous voulons réaliser les fonctions ci-dessus, nous pouvons également le faire en deux étapes. Nous utilisons d’abord IIRF pour la réécriture d’URL au niveau IIS, puis la réécriture d’URL au niveau ASP.NET. Par exemple, si nous voulons maintenant réécrire « http://jeffz.domain.com/articles » en « /ArticleList.aspx?owner=jeffz », nous pouvons d'abord laisser IIRF effectuer la première réécriture d'URL, dans le but de réécrire « /articles » est réécrit en « /ArticleList.aspx ».
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
De cette manière, le moteur ASP.NET recevra directement une requête pour /ArticleList.aspx. Ensuite, dans ASP.NET, nous pouvons effectuer la deuxième réécriture d'URL (pour plus de commodité, je l'écris toujours dans Global.asax, et il est recommandé d'utiliser un HttpModule supplémentaire dans le projet).
protected void Application_BeginRequest (expéditeur de l'objet , EventArgs e)
{
Contexte HttpContext = HttpContext .Current ;
chaîne hôte = contexte.Request.Url.Host ;
propriétaire de chaîne = host.Substring(0, host.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" + propriétaire);
}
Après deux réécritures d'URL, l'effet souhaité a été obtenu (dans les projets réels, le code ci-dessus ne peut pas être utilisé directement car il faut juger s'il existe une chaîne de requête, etc.).
De plus, la réécriture d'URL au niveau ASP.NET ne peut fonctionner que dans ASP.NET (chose évidente). Si vous souhaitez que la réécriture d'URL prenne en charge d'autres technologies de serveur telles que PHP, RoR, etc., vous ne pouvez utiliser que la réécriture d'URL au niveau IIS. (ou autre fonction de réécriture d'URL fournie par la technologie serveur).
Certains caractères spéciaux ne sont pas autorisés à apparaître dans les URL, ou une fois qu'ils apparaissent dans les URL, la signification de la requête est modifiée. Par exemple, nous devons effectuer une réécriture d'URL sur la page de recherche, réécrire "/Search/xxx" en "/Search.aspx?xxx", puis obtenir les mots-clés fournis par l'utilisateur en fonction de la chaîne après le point d'interrogation. Si nous utilisons UrlRewriter.NET, nous utiliserons la configuration suivante :
< rewriter >
< réécrire url = " ^/Recherche/(.+)$ " à = " ~/Search.aspx?$1 " traitement = " arrêter " />
</ rewriter >
Dans des circonstances normales, cette réécriture d'URL fonctionne normalement. Mais si l'utilisateur utilise « % » comme mot-clé, la situation est différente, car nous recevrons l'invite de page d'erreur suivante :
En effet, "%" n'est pas autorisé dans l'URL. Vous pouvez accéder à différents sites Web et essayer de demander certains chemins tels que "ABC%25DEF" ("%25" est suivi de "%"), et la plupart d'entre eux trouveront des erreurs "400 Bad Request". Cependant, il est légal de mettre « % » dans la chaîne de requête - oui, n'avons-nous pas réécrit le mot-clé dans la chaîne de requête ? Pourquoi ça ne marche toujours pas ? Ceci est également déterminé par la manière dont ASP.NET est exécuté.
La mauvaise demande est déterminée à l'étape 3 de la figure ci-dessus, c'est-à-dire alors qu'elle est encore en cours d'initialisation. Notre réécriture d'URL ne se produit que dans l'événement BeginRequest à l'étape 4. Lorsque la requête contient des caractères illégaux, nous n’avons aucune possibilité d’effectuer une réécriture d’URL.
Alors, comment pouvons-nous résoudre ce problème ? Dans des circonstances normales, ce ne sera pas un gros problème si nous supprimons % sur le client (certains sites le font), mais que se passe-t-il si nous devons le conserver ? Utilisez ensuite la chaîne de requête pour transmettre les paramètres, ou nous pouvons également utiliser la réécriture d'URL au niveau IIS. En prenant toujours IIRF comme exemple :
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Lorsque la requête est envoyée à IIS (étape 1), et après avoir sélectionné quel ISAPI doit être transmis terminé pour exécution (étape 2) La réécriture d'URL s'est déjà produite. Après la réécriture de l'URL, le "%" dans l'adresse a été transféré vers la chaîne de requête, et il est naturellement légal lorsqu'il est transmis à ASP.NET pour traitement.
Enfin, discutons de la configuration de la page d'erreur. Par exemple, nous configurerons généralement une page d'erreur 404 pour l'application, de sorte que lorsque l'utilisateur accède à une ressource inexistante, nous puissions lui montrer une page spécifique au lieu de l'invite d'erreur par défaut. Mais à ce stade, différents niveaux de réécriture d’URL doivent être configurés à l’aide de différentes méthodes.
Si nous utilisons la réécriture d'URL au niveau ASP.NET, de manière générale, nous avons configuré le mappage générique dans IIS, afin que toute requête (y compris html, jpg, etc.) soit traitée par ASP.NET. Si une ressource qui n'existe pas est demandée, une erreur 404 sera émise par ASP.NET, la page d'erreur 404 doit donc être configurée dans web.config :
< customErrors mode = " Activé " defaultRedirect = " GenericErrorPage.htm " >
< erreur code d'état = " 404 " redirect = " FileNotFound.htm " />
</ customErrors >
Si nous utilisons la réécriture d'URL au niveau IIS, nous ne configurerons pas le mappage générique. En d'autres termes, le moteur ASP.NET ne commencera à fonctionner que lorsque l'adresse après la réécriture sera aspx (ou d'autres éléments qui auraient dû être gérés par ASP.NET ISAPI). Si l'utilisateur demande une ressource qui n'existe pas, une erreur 404 sera émise par IIS. À ce moment, la page d'erreur 404 doit être configurée dans IIS :
Jusqu’à présent, le sujet de la réécriture d’URL a été abordé. Dans le développement réel, vous rencontrerez certainement diverses situations différentes, mais tant que vous comprenez la clé de la méthode de réécriture d'URL et réfléchissez en fonction de la façon dont le programme s'exécute, je pense qu'en général, vous ne rencontrerez pas de problèmes difficiles.