Wie wir vielleicht wissen, z.B. Was ist der Unterschied zwischen customErrors und httpErrors? , CustomErrors ist eine ältere Möglichkeit, Fehlerseiten in einer Webanwendung zu definieren, aber dieser Ansatz hat einige Probleme - zum Beispiel, wenn Sie sich für korrekte http interessieren Antwortcodes, da der Ansatz von CustomErrors darin besteht, auf eine Fehlerseite umzuleiten, anstatt die aktuelle Antwort zu ersetzen, die den größten Teil der semantischen Integrität der Kommunikation durch HTTP-Statuscodes zerstört.

HttpErrors ist eine neuere Funktion, die seit IIS 7.0 verfügbar ist und auf der Server-Ebene statt der Anwendungsebene und ist viel besser geeignet, um Fehlerreaktionen in einer gültigen Weise zu behandeln, zum Beispiel indem die aktuelle Antwort anstelle der Umleitung verwendet wird.

Allerdings scheint mir die Infrastruktur für diese Artefakte in ASP.NET, wie sie heute aussieht, ein Problem zu sein.

Eine einfache Konfiguration als Beispiel

Wir setzen errorMode auf Custom , weil wir die Fehlerbehandlung selbst testen wollen, und wir setzen existingResponse auf Auto em>, die eine Verzweigung abhängig von einführt Response.TrySkipIisCustomErrors :

• True : Die bestehende fehlerhafte Antwort wird unbehandelt durch dieses Modul geleitet, was angesichts ihrer semantischen Bedeutung absolut Sinn macht.
• False : Die vorhandene fehlerhafte Antwort wird durch das HttpErrors-Modul ersetzt, wenn es eine passende Regel hat, was ebenso sinnvoll ist.

Dies würde idealerweise uns erlauben, einige Fehler selbst zu behandeln, wie wenn das Produkt in ../ product / id nicht existiert, wo wir manuell ein zurücksenden können spezifische 404-Seite mit Informationen über fehlende Produkte und lassen Sie das HttpErrors-Modul weiterhin alle anderen wie ../ products / namebutshouldbeid oder nur ../ mispelledandunmatchableurl .

Soweit ich jedoch sehen kann, funktioniert das nicht. Der Grund dafür ist in der internen Methode System.Web.HttpResponse . ReportRuntimeError , das bei Laufzeitfehlern aufgerufen wird (z. B. Controller / Aktionen nicht gefunden) und wo wir einen Abschnitt haben, der so aussieht:

Beim ersten Debugging habe ich gesehen, dass useCustomErrors auf false gesetzt wurde, und ich konnte nicht verstehen, warum, da ich wusste, dass ich eine funktionierende HttpError -Konfiguration hatte, da sie funktioniert Ich gebe ein HttpNotFoundResult aus ein Controller.

Dann habe ich festgestellt, dass dies nicht HttpErrors ist, sondern die älteren CustomErrors . Und die CustomErrors haben offensichtlich keine Kenntnis von HttpErrors .

Der "Fehler"

Was also passiert ist Response .TrySkipIisCustomErrors wird auf "True" gesetzt, und da keine CustomErrors definiert sind, wird die detaillierte 404-Antwort zurückgegeben. An dieser Stelle möchten wir, dass HttpErrors sich einschaltet, aber es wird nicht wegen TrySkipIisCustomErrors jetzt auf true gesetzt.

Und CustomErrors können wir auch nicht verwenden, da wir damit auf die Probleme mit abstoßenden Fehlerumleitungen zurückkommen.

Und der Grund, warum HttpNotFoundResult funktioniert, weil es keinen Laufzeitfehler auslöst, sondern nur ein 404-Ergebnis liefert, das HttpErrors wie erwartet abfängt, solange wir es vermeiden, Response.TrySkipIisCustomErrors zu true.

Wie sollte / könnte das gehandhabt / gelöst werden?

Ich denke, dass System.Web.HttpResponse .ReportRuntimeError sollte nicht Response.TrySkipIisCustomErrors standardmäßig auf" true ", da wir davon ein anderes Fehlerbehandlungsmodul haben. Daher muss diese Methode jedes HttpErrors Konfiguration, entweder indem Sie TrySkipIisCustomErrors auf true setzen, wenn wir CustomErrors Konfiguration, oder dass es die HttpErrors Konfiguration zusammen mit der CustomErrors Konfiguration behandelt.

Oder habe ich eine geheime Magie verpasst, um das zu lösen?