Dans l'article http://www.webreference.com/new/011004.html vous avez appris comment créer un écran d'erreur 404 personnalisé qui propose de revenir à la page précédente, donner des liens vers des parties principales du site etc (sinon, faites un saut sur cette page avant de continuer la lecture de l'article).
L'objet de notre article est de savoir si nous pouvons utiliser le mécanisme de redirection pour d'autres raisons. Nous en avons trouvé quelques unes :
L'erreur 404 apparaît si la page demandée est statique. N'oubliez pas de paramétrer les messages d'erreur 403 pour les appels erronés des scripts asp, php, jsp ... Vous pouvez faire la redirection sur la même page de gestion de l'erreur.
La page d'affichage d'erreur est, en général, unique pour tout le site web. Si IIS détecte un lien erroné dans un répertoire existant de votre site, il exécute la page d'erreur dans le contexte de ce répertoire. Si, sur votre page d'erreur vous affichez des images ou intégrez des jscripts en indiquant un chemin relatif, cela risque de ne pas marcher.
Exemple : vous avez un répertoire www.mysite.com/products/.
Votre page d'erreur se trouve dans la racine du site : www.mysite.com/err_404.asp Sur votre page d'erreur, vous affichez le logo de la société : <img src="images/logo.gif">
Si l'utilisateur demande un lien erroné www.mysite.com/abc.htm, l'image est affichée correctement. Par contre, si la demande est www.mysite.com/products/abc.htm, le script err_404.asp est exécuté, mais l'image ne sera pas affichée.
Pour résoudre ce problème, utilisez des chemins url absolus ou ajoutez une redirection supplémentaire dans la page err_404.asp sur elle-même pour changer le contexte : Response.Redirect("/err_404.asp?" & Request.QueryString)
Faites très attention aux variables "HTTP-REFERRER" et "HTTP-HOST" car ces données sont souvent cachées ou déformées par les serveurs proxy. Evitez de baser vos scripts importants sur ces variables.
1. Assurer les liens après la restructuration du site.
Votre site est connu par vos partenaires, par les moteurs de recherches et par les internautes au travers de liens vers ses différentes pages. Au fil du temps, il est amené à subir des changements au niveau de l'information mise en ligne, comme la structure de pages, scripts et images. Quand vous changez l'adresse d'une page, vous êtes obligé de soutenir en quelque sorte l'adresse précédente, car les ressources externes afficheront toujours le lien vers l'adresse précédente.
Vous pouvez créer un Jscript de redirection ou des tags <META> permettant de réaliser la redirection vers la nouvelle adresse, mais cela vous oblige à garder quand même un morceau de code à l'ancienne adresse. Le moyen d'éviter cela est d'utiliser le mécanisme de redirection de l'erreur 404.
Supposons que vous avez une page de présentation de produit à l'adresse suivante :
www.fw-application.com/quality/ml_demo.asp
Cette présentation se développe par la suite vers une série de pages contenant la spécification, les fonctionnalités, les événements associés, vous préférez grouper ces pages sous un code de produit, par exemple 02. Les pages du sites deviennent :
www.fw-application.com/prd02_01.asp - spécification
www.fw-application.com/prd02_03.asp - fonctionnalités
...
www.fw-application.com/prd02_05.asp - démo
....
Donc, notre lien ml_demo.asp est devenu prd02_05.asp. Comment faire pour rediriger les appels de l'ancienne adresse ?
1. Supprimez la page ml_demo.asp
2. Dans le script d'affichage de l'erreur 404, avant toute réponse au client, réalisez un test de lien erroné :
<% tmpExpr = Request.QueryString.Key(1) if not instr(tmpExpr,"ml_demo.asp")=0 then Response.Redirect("/prd02_05.asp") end if %>
Votre redirection est assurée.
Pour généraliser notre petit "routeur", créons une fonction de test :
<% Sub RedirectRequest(RequestedPage, RedirectPage) if not instr(tmpExpr,RequestedPage)=0 then ' variable tmpExpr étant une variable globale Response.Redirect(RedirectPage) end if end sub %>
avec des appels :
<% if Request.QueryString.Count=1 then tmpExpr = Request.QueryString.Key(1) RedirectRequest "ml_demo.asp", "/prd02_05.asp" end if %>
Pourquoi avons- nous ajouté un test sur le nombre de paramètres de type "Get" ? Parce que si la page est appelé avec plus de paramètres, cela veut dire que ce n'est pas IIS qui a fait la redirection.