Ich habe ein ziemlich interessantes Problem mit der benutzerdefinierten Fehlerseitenverwaltung für eine neue ASP.NET MVC-Anwendung.
Dieses Problem ist wie folgt:
- Wenn ich eine URL (egal welche) mit einem "schlechten" Argument am Ende der URL anrufe, wie ..../c< , zeigt die Anwendung die korrekte Serverfehlerseite an, wie in der web.config; .../<c (um mehr wie ein HTML-Tag zu sehen, wird keine Serverfehlerseite im Browser angezeigt und stattdessen bekomme ich einen einfachen YSOD mit einer Nachricht wie An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
Laut ELMAH, beide Anträge mit einem 400 Status-Code und die Nachricht endete:
- für den ersten: System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (<).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
- für die zweite: System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (<).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Beide Fehler sind also gleich, der Statuscode ist derselbe, aber für einen der Fehler wird die benutzerdefinierte Fehlerseite nicht angezeigt. Ich bin auch im debug-Modus auf global.asax gegangen und habe die Server.GetLastError() in protected void Application_Error(object sender, EventArgs e) überprüft und wieder waren beide Fehler gleich, nichts ist anders.
In web.config sieht mein <customErrors> -Tag so aus:
<customErrors mode="On" defaultRedirect="/ServerError.aspx" redirectMode="ResponseRewrite">
<error statusCode="500" redirect="/ServerError.aspx" />
<error statusCode="404" redirect="/PageNotFound.aspx" />
</customErrors>
Kann mir bitte jemand sagen, warum das Verhalten in diesen beiden Fällen anders ist?
Vielen Dank für Ihre Zeit.
Es gibt viele Fehlinformationen und / oder veraltete Lösungen in Bezug auf die Fehlerbehandlung in IIS 7+. Die wichtigsten Dinge zu verstehen sind: -
Die meisten Leute verwenden Mischlösungen, die alle customErrors , httpErrors , Application_Error enthalten und setzen oft requestValidationMode="2.0" auf die Eigenschaft httpRuntime und / oder deaktivieren die Anforderungsprüfung vollständig! Dies macht es wirklich schwierig, die Lösungen anderer Leute zu verwenden, weil alle und alle diese das Verhalten beeinflussen können. Ich musste mich schnell umsehen und fand wahrscheinlich einige Semi-Duplikate ohne akzeptierte Antworten, wahrscheinlich aus diesem Grund.
Der Grund dafür, dass diese beiden Fehler zu einem unterschiedlichen Verhalten führen, liegt darin, dass sie in verschiedenen Phasen in der Anforderungspipeline auftreten . Der customErrors -Knoten in Ihrem web.config interagiert mit Fehlern " innerhalb " Ihrer Anwendung, während die Anforderungsvalidierung " außerhalb " Ihrer Anwendung stattfindet. IIS lehnt die gefährliche Anforderung ab, bevor sie in Ihren Anwendungscode einfügt, und Ihr customErrors Ersatz tritt nicht auf.
Also, wie reparieren wir das?
Idealerweise möchten Sie eine Lösung mit möglichst wenigen beweglichen Teilen. IIS7 gibt uns eine neue Möglichkeit, Fehlerseitenersetzung auf der IIS-Ebene statt auf der Anwendungsebene anzugeben - den Knoten httpErrors . Dadurch können wir alle unsere Fehler an einem Ort abfangen: -
Wenn Sie sich für SEO interessieren (und das sollten Sie!), müssen Sie immer noch sicherstellen, dass Ihr Controller / Ihre Seite einen entsprechenden Statuscode einstellt: -
%Vor% Sie sollten Ihren customErrors Knoten vollständig entfernen. Es wird normalerweise für die Abwärtskompatibilität verwendet. Sie sollten auch sicherstellen, dass requestValidationMode nicht auf dem Knoten httpRuntime festgelegt ist.
Dies sollte die meisten Fehler (abgesehen natürlich, Fehler beim Parsen Ihrer web.config!) fangen.
Related: - ASP.NET MVC benutzerdefinierte Fehler
MSDN-Dokumentation: - Ссылка
Hinweis: Wenn Sie in Ihrem Fall defaultPath für den Knoten httpErrors festlegen möchten, erhalten Sie eine Sperre wegen der ApplicationHost.config -Einstellungen. Sie können entweder tun, was ich getan habe, und einfach path für die Fehlercodes, die Ihnen wichtig sind, einzeln einstellen, oder Sie können sich die Freigabe des Knotens ansehen: -
Meine Intuition ist, dass es in Umgebungen mit geringer Kontrolle wie Azure App Service / Azure-Websites mehr Probleme bereitet als es lohnt. Sie können auch die Pfade für einzelne Statuscodes festlegen.
Ich habe ein vollständig funktionierendes Beispiel der Verwendung von httpErrors für benutzerdefinierte Fehlerseiten auf github eingefügt. Sie können es auch live auf azurblauen Websites sehen .
Tags und Links asp.net-mvc c# asp.net