J'ai remarqué un comportement étrange dans les pages d'erreur IIS. J'ai cette configuration:
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="500" />
<error statusCode="500" responseMode="ExecuteURL" path="/error-page" />
</httpErrors>
Parfois, lorsqu'une erreur ASP.NET se produit en raison de la chaîne de requête trop longue, la deuxième erreur se produit immédiatement lors de la tentative d'exécution de l'URL de la page d'erreur. J'ai suivi le problème jusqu'au fait que IIS ajoute l'URL d'origine à l'URL de la page d'erreur comme:
Original: http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Error: /error-page?500;http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Ceci est un énorme problème. Si l'URL d'origine échoue pour avoir une chaîne de requête trop longue, la page d'erreur avec les éléments ajoutés échoue également car elle a une chaîne de requête encore plus longue!
Je crois que c'est le bogue le plus stupide dans IIS. Est-ce que quelqu'un sait s'il y avait un patch de service pack pour cela? Dans le pire des cas, si rien n'est résolu maintenant, existe-t-il un moyen de désactiver ce comportement ou des astuces pour empêcher IIS d'ajouter des éléments non sollicités à la page d'erreur? Parce qu'il brise tout le mécanisme de la page d'erreur personnalisée.
Réponses:
L'ajout d'une barre oblique de fin au chemin (par exemple, path = "/ page-erreur /") arrêtera le code d'erreur et l'URL ajoutés, notez qu'il conservera l'URL défaillante d'origine, par exemple
la source
J'ai un problème similaire il y a longtemps, le système en question utilise des pages d'erreur statiques à cause de cela.
Vous pouvez définir cela dans le defaultResponseMode sur un fichier qui servira de retour à une seule page statique.
Schéma des paramètres IIS de l'élément httpErrors
Il y a aussi un problème similaire ici
la source