CustomErrors ne fonctionne pas lorsque l'on définit redirectMode="ResponseRewrite".

Question

Dans un ancien site, je modifiais le mode de fonctionnement de CustomErrors en ajoutant redirectMode="ResponseRewrite" (nouveau dans 3.5 SP1) :

<customErrors mode="RemoteOnly" defaultRedirect="Error.aspx" redirectMode="ResponseRewrite">
    <error statusCode="404" redirect="404.aspx" />
</customErrors> 

Le problème, c'est qu'il m'affiche la page d'erreur générique (celle que l'on obtient lorsqu'on n'a pas configuré l'option customErrors . Si je retire le redirectMode="ResponseRewrite" partie, cela fonctionne bien.

Je suis sûr que 3.5 SP1 est installé sur le serveur, car j'utilise le même paramètre sur d'autres sites hébergés sur le même serveur.

Des idées ?

Answer 1

Il est important de noter pour quiconque essaie de faire cela dans une application MVC que ResponseRewrite utilise Server.Transfer dans les coulisses. Par conséquent, le defaultRedirect doit correspondre à un fichier légitime sur le système de fichiers. Apparemment, Server.Transfer n'est pas compatible avec les routes MVC. Par conséquent, si votre page d'erreur est servie par une action de contrôleur, Server.Transfer va chercher /Error/Whatever, ne pas le trouver sur le système de fichiers, et retourner une page d'erreur générique 404 !

Answer 2

Le seul moyen qui a parfaitement fonctionné pour moi est de désactiver les erreurs personnalisées et de remplacer les pages d'erreur d'iis via web.config. Cela envoie le code d'état correct avec la réponse et a l'avantage de ne pas passer par la mvc.

voici le code

1. Désactiver les erreurs personnalisées

   <customErrors mode="Off" />

2. Remplacer les pages d'erreur

   <httpErrors errorMode="Custom" existingResponse="Replace">
     <remove statusCode="404" subStatusCode="-1" />
     <remove statusCode="500" subStatusCode="-1" />
     <error statusCode="404" path="Error404.html" responseMode="File" />
     <error statusCode="500" path="Error.html" responseMode="File" />
   </httpErrors>

Note. Utilisez responsemode="file" si l'url est un lien direct vers un fichier

info : http://tipila.com/tips/use-custom-error-pages-aspnet-mvc

Answer 3

Ce qui se passe, c'est que IIS voit le code d'état d'erreur et présente sa propre page d'erreur au lieu de la vôtre. Pour résoudre ce problème, vous devez définir ce paramètre dans le code derrière la page de votre page d'erreur pour empêcher IIS de faire cela :

Response.TrySkipIisCustomErrors = true;

Cela ne fonctionne qu'avec IIS7 ou une version supérieure. Pour les versions antérieures d'IIS, vous devrez jouer avec les paramètres de la page d'erreur.

Answer 4

Je sais que cette question est un peu ancienne, mais j'ai pensé que je devais signaler qu'il n'est pas nécessaire que ce soit un fichier statique pour que cela fonctionne.

J'ai rencontré un problème similaire, et c'est juste une question de trouver cette erreur dans votre Error.aspx, dans notre cas, c'était parce que la page maître utilisée dépendait d'un élément de données de session et lorsque ResponseRewrite a été activé, la session n'est pas disponible pour notre page Error.aspx.

Je n'ai pas encore déterminé si cette indisponibilité de la session est due à la configuration spécifique de notre application ou à une partie "par conception" d'ASP.net.

Answer 5

J'ai trouvé que le problème était dans Error.aspx. Je n'arrive toujours pas à trouver quelle est l'erreur réelle dans error.aspx qui cause le problème.

Le changement de la page en un fichier html statique a résolu le problème.