Was ist der Unterschied zwischen customErrors und httpErrors?

Was ist der Unterschied zwischen den Abschnitten customErrorsund httpErrorsder Datei web.config in ASP.NET MVC-Anwendungen?

Was sind die Richtlinien für die Verwendung der einzelnen Abschnitte?

Haftungsausschluss: Dies ist aus meiner Erfahrung und nicht nachgewiesene Tatsache.

Beide werden verwendet, um die Fehlerbehandlung für eine Website zu definieren, aber unterschiedliche Software bezieht sich auf unterschiedliche Konfigurationselemente.

customErrors sind ein altes (abwärtskompatibles) Element, das von Visual Studio Development Server (auch bekannt als VSDS oder Cassini) verwendet wird.

httpErrors sind das neue Element, das nur von IIS7 verwendet wird.

Dies unterstreicht das mögliche Problem bei der Entwicklung von ASP.NET-Websites unter Verwendung von VSDS anstelle des lokalen IIS.

Außerdem finden Sie in diesem Beitrag von mir , wie Fehlermeldungen mit IIS7 zu handhaben , wenn Sie die volle Kontrolle über die Fehlerausgabe haben möchten.

Zusammenfassung:

• In- VSDSUse entwickelncustomErrors
• Veröffentlichen der Website IIS6- NutzungcustomErrors
• Veröffentlichen der Website IIS7- Nutzung httpErrors.

und wenn Sie mit entwickeln, VSDSaber veröffentlichen IIS7, dann werden Sie wahrscheinlich beides brauchen.

* Aktualisiert im April 2016

Das customErrors-Attribut wird verwendet, wenn der .net-Code eine Ausnahme auslöst (404, 403, 500 usw.), und das httpErrors-Attribut wird verwendet, wenn IIS selbst eine Ausnahme auslöst.

• / myfakeextensionslessurl -> httpErrors 404
• /myfakeaspsx.aspx -> customErrors 404
• /myfakeimage.jpg -> httpErrors 404
• /throw500.apx -> customErrors 500
• / throw500 -> customErrors 500

Es gibt viele Fallstricke, die versuchen, dies richtig zu konfigurieren. Wenn Sie also nach einem kurzen Beispiel suchen, sind die besten 2 Optionen, die Sie haben:

Beispiel 1: Verwenden von HTML-Seiten

<system.web>
  <customErrors mode="RemoteOnly" defaultRedirect="/Error500.html" redirectMode="ResponseRewrite">
    <error statusCode="403" redirect="/Error403.html" />
    <error statusCode="404" redirect="/Error404.html" />
    <error statusCode="500" redirect="/Error500.html" />
  </customErrors>
</system.web>
<system.webServer>
  <httpErrors errorMode="DetailedLocalOnly" existingResponse="Auto">
    <remove statusCode="403" />
    <remove statusCode="404" />
    <remove statusCode="500" />
    <error statusCode="403" responseMode="File" path="Error403.html" />
    <error statusCode="404" responseMode="File" path="Error404.html" />
    <error statusCode="500" responseMode="File" path="Error500.html" />
  </httpErrors>
</system.webServer>

Beispiel 2: Verwenden von Aspx-Seiten

<system.web>
  <customErrors mode="RemoteOnly" defaultRedirect="/Error500.html" redirectMode="ResponseRewrite">
    <error statusCode="403" redirect="/Error403.aspx" />
    <error statusCode="404" redirect="/Error404.aspx" />
    <error statusCode="500" redirect="/Error500.aspx" />
  </customErrors>
</system.web>
<system.webServer>
  <httpErrors errorMode="DetailedLocalOnly" existingResponse="Auto">
    <remove statusCode="403" />
    <remove statusCode="404" />
    <remove statusCode="500" />
    <error statusCode="403" responseMode="ExecuteURL" path="Error403.aspx" />
    <error statusCode="404" responseMode="ExecuteURL" path="Error404.aspx" />
    <error statusCode="500" responseMode="ExecuteURL" path="Error500.aspx" />
  </httpErrors>
</system.webServer>

Und auf den Aspx-Fehlerseiten müssen Sie Folgendes tun (Beispiel 404-Seite):

<% 
    Response.StatusCode = 404;
    Response.TrySkipIisCustomErrors = true;
 %>

Hinweis: Die Verwendung von URLs ohne Erweiterung im Abschnitt customErrors ist nicht möglich! . (ohne Hacks)

Eine Problemumgehung besteht darin, benutzerdefinierte Fehler zu deaktivieren und http-Fehler die benutzerdefinierte Seite behandeln zu lassen. Ein Freund hat ein solches Setup erstellt. Wenn ich etwas Zeit finde, werde ich den Code freigeben.

Hintergrund

Eine gute benutzerdefinierte Fehlerseite wird:

1. Zeigen Sie die echte Ausnahme an, wenn Sie die Problemseite lokal besuchen
2. Zeigen Sie eine benutzerdefinierte Seite an, wenn Sie die Problemseite remote besuchen
3. Leitet nicht weiter, sondern zeigt einfach den Inhalt der Fehlerseite an (aus SEO-Gründen)
4. Zeigt den richtigen Statuscode an

Um einige Optionen in unserer Konfiguration zu verdeutlichen:

1. <customErrors mode="RemoteOnly". Sie können hier angeben: On, Off, RemoteOnly.

   • On = Benutzerdefinierte Fehlerseiten immer anzeigen
   • Off = Zeige immer den wirklichen Fehler
   • RemoteOnly= Zeigen Sie den Fehler lokal an, aber zeigen Sie die benutzerdefinierte Fehlerseite remote an. Also wollen wir RemoteOnlyfür Aussage 1

2. <customErrors redirectMode="ResponseRewrite". Hier können Sie angeben: ResponseRedirectoder ResponseRewrite. Der ResponseRedirectModus leitet die Fehlerseite zur benutzerdefinierten Fehlerseite um. Für einen Linkcrawler (SEO) führt dies zu 302 -> 500, aber Sie möchten, dass der Linkcrawler einen Fehler von 500 erhält.

3. <httpErrors errorMode="DetailedLocalOnly". Dies entspricht dem customErrorsModus. Optionen , die Sie haben: Custom, Detailed, DetailedLocalOnly.

Ein guter Blog-Beitrag, der mir sehr geholfen hat, ist: http://benfoster.io/blog/aspnet-mvc-custom-error-pages

<customErrors> gegen <httpErrors>

<customErrors>

• noch verfügbar in IIS7 +
• Geben Sie benutzerdefinierte Fehlerseiten für Anforderungen an, die von ASP.NET verarbeitet werden
• verarbeitet nur Anforderungen innerhalb der ASP.NET-Anwendung
• statische Dateien wie HTML-Dateien oder Verzeichnis-URLs ("freundliche") werden nicht behandelt

<httpErrors>

• eingeführt in IIS7
• Geben Sie benutzerdefinierte Fehlerseiten für Anforderungen an, die von IIS verarbeitet werden
• verarbeitet Anforderungen innerhalb der ASP.NET-Anwendung UND / ODER verarbeitet Anforderungen außerhalb der ASP.NET-Anwendung *
• Alle Dateien und URLs werden behandelt *

Hinweis: Die Verwendung ist nicht mehr erforderlich customErrors

Zitierte Quelle: Benutzerdefinierte 404- und Fehlerseiten in ASP.NET (ausgezeichneter Artikel)

ExecuteURLdient dynamischen Inhalten wie einer ASPX-Seite (der pathWert muss eine serverbezogene URL sein ):

<system.webServer>
  <httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL" >
    <remove statusCode="404"/>
    <error statusCode="404" responseMode="ExecuteURL" path="/error.aspx" />
  </httpErrors>
</system.webServer>

File liefert eine benutzerdefinierte Fehlerdatei, z. B. eine HTML-Seite:

<system.webServer>
  <httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="File" >
    <remove statusCode="404"/>
    <error statusCode="404" path="404.html" />
  </httpErrors>
</system.webServer>

Referenz: HTTP-Fehler (www.iis.net)

Weitere Informationen finden Sie unter dem obigen Link www.iis.net

Der Abschnitt "Fehler" in der Webkonfiguration dient zum Bereitstellen eines benutzerdefinierten http-Fehlerbehandlungsansatzes. Es gibt zwei Abschnitte, einen benutzerdefinierten Fehler im Abschnitt system.web und einen weiteren httpErrors im Abschnitt system.webServer (wie unten angegeben).

customErrors: Dieser Abschnitt wurde vor der Einführung von IIS 7, IIS 6 5 und vor der vollständigen Verwendung dieses Abschnitts zur Behandlung von benutzerdefinierten http-Fehlern gemäß dem http-Statuscode verwendet.

httpErrors: IIS 7 und höher verwenden diesen Abschnitt sowie den Abschnitt customErrors , um benutzerdefinierte http-Fehler basierend auf ihren Dateierweiterungen zu behandeln, wenn die angeforderte Seitenerweiterung mit ISAPI-DLL (.aspx, ashx, .asmx, .svc usw.) wie index.aspx registriert wird IIS-Aufnahmeeinstellung aus dem Abschnitt customeErrors, andernfalls wird die Einstellung von httpErrors übernommen (der von IIS 7 gehostete Modus muss als integrierte Stimmung und nicht als klassisch eingestellt sein).

Nachfolgend finden Sie die Beispiele für den Link zur Überprüfung der 404-Fehlerbehandlung:

httperrors vs customerrors in webconfig, iis, asp.net