Heim > Artikel > Backend-Entwicklung > Benutzerdefinierte ASP.NET MVC-Fehlerseite

Benutzerdefinierte ASP.NET MVC-Fehlerseite

高洛峰Original: 2016-12-24 13:48:511571Durchsuche

Wenn Sie Probleme beim Einrichten benutzerdefinierter asp.net mvc-Fehlerseiten haben, sind Sie nicht allein. Ich bin überrascht, dass Ihr Ansatz richtig ist. Der Grund, warum er nicht funktioniert, ist, dass ein Teil der Fehler von der asp.net-Pipeline und der andere Teil direkt von iis behandelt wird.

Normalerweise (ich gehe davon aus, dass dies bei einigen anderen Frameworks/Servern der Fall sein wird) müssen wir nur die benutzerdefinierte Fehlerseite an einer Stelle konfigurieren, unabhängig davon, wo der Fehler auftritt. So:

<customErrors mode="On">
  <error code="404" path="404.html" />
  <error code="500" path="500.html" />
</customErrors>

Benutzerdefinierte 404-Fehlerseite

Wenn eine Ressource nicht vorhanden ist (einschließlich statischer und dynamischer Ressourcen), müssen wir dies tun Geben Sie eine 404-Statusseite zurück. Normalerweise müssen wir einige leicht benutzerfreundliche Informationen bereitstellen, um die von asp.net/iis generierte Standardfehlerseite zu ersetzen und unseren Website-Besuchern angezeigt zu werden. Möglicherweise geben wir Hinweise, warum die Ressource möglicherweise nicht vorhanden ist, oder stellen Optionen bereit Website zum Durchsuchen.

Die einfachen Einstellungen hier nur zur Demonstration sind wie folgt:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8"/>
  <title>404 Page Not Found</title>
</head>
<body>
  <h1>404 Page Not Found</h1>
</body>
</html>

Ich habe eine neue ASP.NET MVC 5-Anwendung erstellt, einschließlich Die Standardvorlage, die mit vs. geliefert wird. Wenn ich es ausführe und versuche, zu einem nicht vorhandenen Pfad zu navigieren, z. B. /foo/bar, erhalte ich eine Standard-ASP.NET 404-Seite mit den folgenden Informationen:

ASP.NET MVC自定义错误页面

Nein Zu freundlich, nicht wahr?

Der Fehler wird in diesem Fall von ASP.NET MVC ausgelöst, da kein Controller oder keine Aktion gefunden wird, die mit der URL übereinstimmt.

Um die 404-Fehlerseite anzupassen, im Konfigurationsabschnitt 2dc15ec6bc814c3aa45b55d017848bed4ec4537ca3582453b3a7c44816bcf480 von web.config:

<customErrors mode="On">
 <error statusCode="404" redirect="~/404.html"/>
</customErrors>

mode="On" damit wir die Fehlerseite lokal sehen können. Normalerweise möchten Sie möglicherweise mode="RemoteOnly" festlegen, um nur bei Verwendung zu rendern.

Wenn ich jetzt erneut zu /foo/bar navigiere, kann ich die Fehlerseite sehen, die ich gerade definiert habe.

Wie erwartet lautet der URL-Pfad jedoch zu diesem Zeitpunkt nicht /foo/bar ASP.NET leitet es an /404.html?aspxerrorpath=/foo/bar weiter und ich habe überprüft, dass der HTTP-Statuscode der Antwort ebenfalls ein normaler 200 ist.

Das ist sehr schlecht. Die Rückgabe des http-Codes 200 ist nicht nur irreführend, sondern auch schlecht für SEO. Einfach ausgedrückt: Wenn die Ressource im angegebenen Pfad nicht vorhanden ist, sollte 404 zurückgegeben werden. Wenn die Ressource verschoben wird, sollte sie auf den neuen Pfad umgeleitet werden.

Um dieses Problem zu beheben, können wir das ASP.NET-Standardverhalten der Umleitung der Fehlerseite ändern, um die Antwort neu zu schreiben.

<customErrors mode="On" redirectMode="ResponseRewrite">
 <error statusCode="404" redirect="~/404.html"/>
</customErrors>

Dies hat jedoch keine große Auswirkung (dieser Ausländer ist wirklich ausführlich, obwohl die ursprüngliche URL-Adresse nicht umgeleitet wurde, ASP.NET). Gibt immer noch 200 zurück und zeigt zusätzlich unsere benutzerdefinierte Fehlerseite als Klartext an.

Es scheint, dass wir zu einer ASP.NET-Seite zurückkehren müssen. Wenn Sie vorher dachten, Sie müssten nicht zur *.aspx-Seite gehen, dann habe ich Sie leider enttäuscht.

Nach dem Ändern der Fehlerseite und der entsprechenden web.config auf 404.aspx sind die URL und der Inhaltstyp (Text/HTML) normal.

Aber das Problem von 200 besteht noch immer. Microsoft hat offiziell eine entsprechende Lösung für dieses Problem bereitgestellt – das Festlegen des Statuscodes der Seite. Wir fügen den folgenden Teil zu 404.aspx hinzu:

< ;% Response.StatusCode = 404 %>

Wir haben jetzt den richtigen Statuscode, die richtige URL und die benutzerdefinierte Fehlerseite. Ist das erledigt?

Falsch.

Wenn wir auf einen statischen Seitenpfad (z. B. foo.html) oder eine URL verlinken, die nicht mit unserer Routing-Konfiguration übereinstimmt (z. B. /foo/bar/foo/bar), Wir sehen eine Standard-IIS-404-Fehlerseite.

Die obige Situation umgeht ASP.NET und IIS verarbeitet die Anfrage. Wenn Sie im Controller ein HttpNotFound() zurückgeben, erhalten Sie natürlich dasselbe Ergebnis. Dies liegt daran, dass MVC einfach den Statuscode festlegt und keinen Fehler auslöst, sondern ihn an IIS übergibt.

In diesem Fall müssen wir die Fehlerseite von iS festlegen (nur gültig für IIS). 7+) .Im Konfigurationsabschnitt web.config 1dcc4c920d99d48189de261dfba48f618949b9d1274f3c945159f8136aaa1284:

<httpErrors errorMode="Custom">
 <remove statusCode="404"/>
 <error statusCode="404" path="/404.html" responseMode="ExecuteURL"/>
</httpErrors>

Stellen Sie außerdem errorMode= ein „Benutzerdefiniert“ Für lokale Tests. Normalerweise wird es auf errorMode="DetailedLocalOnly" eingestellt.

Beachten Sie, dass ich eine HTML-Seite anstelle von ASPX verwendet habe. Normalerweise sollten Sie als Fehlerseiten einfache statische Dateien verwenden, damit die Fehlerseite auch dann noch angezeigt werden kann, wenn ein ASP.NET-Fehler auftritt.

Wenn wir nun zu einem statischen Dateipfad navigieren, der nicht existiert, erhalten wir eine benutzerdefinierte Fehlerseite anstelle der IIS-Standardseite 404. Der Rest ist immer noch das gleiche 200-Problem wie zuvor.

Glücklicherweise bietet IIS tatsächlich eine integrierte Lösung für dieses Problem. Wenn Sie „responseMode="File" festlegen, gibt IIS Ihre benutzerdefinierte Fehlerseite zurück, ohne die ursprünglichen Antwortheader zu ändern:
523dd5a79270d9ce6eaad7e519283757
Fertig.

Angepasste 500-Fehlerseite

Das meiste davon ist nichts weiter als das Kopieren der oben genannten Lösung und das Hinzufügen einer benutzerdefinierten 500-Fehlerseite. Hier gibt es einige Dinge, die es zu beachten gilt.

标准的 ASP.NET MVC模板内置的 HandleErrorAttribute 作为一个全局过滤器。捕获在ASP.NET MVC管道引发的任何错误，并返回一个自定义"错误"视图提供你有在web.config中启用自定义错误。它会寻找 ~/views/{controllerName}/error.cshtml 或 ~ / views/shared/error.cshtml。

如果你使用了过滤器（filter），你需要更新现有的自定义错误视图，并不存在的则需要创建（最好放在views/shared文件夹下）

我没有看见这个filter有可以设置的属性值,在 MVC 管道引发的任何异常都会退回到标准的 ASP.NET 错误配置页面，既然你要设置那些**那这里就用不到这个filter。

添加如下自定义错误页配置：

<customErrors mode="On" redirectMode="ResponseRewrite">
 <error statusCode="404" redirect="~/404.aspx"/>
 <error statusCode="500" redirect="~/500.aspx"/>
</customErrors>

类似于前面创建的404.aspx：

<% Response.StatusCode = 500 %>
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>500 Server Error</title>
</head>
<body>
  <h1>500 Server Error</h1>
</body>
</html>

不幸的是这样做并不会捕获到你应用程序中的每一个异常。一个相当常见的错误——由 ASP.NET 产生的请求的验证，如一个危险的url路径/foo/bar3f1c4e4b6b16bbbd69b2ee476dc4f83a2cacc6d41bbb37262a98f745aa00fbf0 ，这个实际上会产生一个404响应；因此你可以添加一个默认错误配置：

<customErrors mode="Off" redirectMode="ResponseRewrite" defaultRedirect="~/500.aspx">
 <error statusCode="404" redirect="~/404.aspx"/>
 <error statusCode="500" redirect="~/500.aspx"/>
</customErrors>

最后为了捕获非ASP.NET异常我们设置IIS自定义服务器内部错误500错误页面：

3b10f7d8ee3c92e519d014c43734687b

总结

在你的应用程序根目录创建如下错误页面:

404.html - for IIS
404.aspx - for ASP.NET
500.html - for IIS
500.aspx - for ASP.NET

确认您设置在 ASPX 页面内的适当响应状态码.

抛弃 MVC HandleErrorAttribute 全局筛选器；配置 ASP.NET 的自定义错误:

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

配置IIS自定义错误页:

<httpErrors errorMode="DetailedLocalOnly">
 <remove statusCode="404"/>
 <error statusCode="404" path="404.html" responseMode="File"/>
 <remove statusCode="500"/>
 <error statusCode="500" path="500.html" responseMode="File"/>
</httpErrors>

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持PHP中文网。

更多ASP.NET MVC自定义错误页面相关文章请关注PHP中文网！

Stellungnahme：

Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn

Vorheriger Artikel：[C#-Tutorial] Überladen von C#-OperatorenNächster Artikel：[C#-Tutorial] Überladen von C#-Operatoren

In Verbindung stehende Artikel

Mehr sehen