IIS7 Überschreibt customErrors beim Festlegen von Response.StatusCode?

Ich habe hier ein komisches Problem. Jeder weiß, dass Sie, wenn Sie den customErrorsAbschnitt von web.config verwenden , um eine benutzerdefinierte Fehlerseite zu erstellen, die entsprechende Einstellung vornehmen sollten Response.StatusCode. Wenn ich beispielsweise eine benutzerdefinierte 404-Seite erstelle und sie 404.aspx nenne, kann ich <% Response.StatusCode = 404 %>den Inhalt einfügen, damit er einen echten 404-Statusheader hat.

Folge mir so weit? Gut. Versuchen Sie dies jetzt auf IIS7. Ich kann es nicht zum Laufen bringen, Punkt. Wenn dies Response.StatusCodeauf der benutzerdefinierten Fehlerseite festgelegt ist, scheint IIS7 die benutzerdefinierte Fehlerseite vollständig zu überschreiben und zeigt eine eigene Statusseite an (falls Sie eine konfiguriert haben).

Hat jemand anderes dieses Verhalten gesehen und weiß vielleicht auch, wie man es umgeht? Es hat unter IIS6 funktioniert, daher weiß ich nicht, warum sich die Dinge geändert haben.

Hinweis: Dies ist nicht dasselbe wie das Problem in ASP.NET Custom 404, das 200 OK anstelle von 404 Not Found zurückgibt

Setzen Sie im Abschnitt system.webServer / httpErrors die vorhandene Antwort auf PassThrough:

  <system.webServer>
    <httpErrors existingResponse="PassThrough" />
  </system.webServer>

Der Standardwert der vorhandenenResponse-Eigenschaft ist Auto:

Auto weist das benutzerdefinierte Fehlermodul an, das Richtige zu tun. Der tatsächliche Fehlertext, der von Clients angezeigt wird, hängt vom Wert des im IHttpResponse::GetStatusAufruf zurückgegebenen fTrySkipCustomErrors ab . Wenn fTrySkipCustomErrors auf true gesetzt ist, lässt das benutzerdefinierte Fehlermodul die Antwort durch. Wenn es jedoch auf false gesetzt ist, ersetzt das benutzerdefinierte Fehlermodul den Text durch seinen eigenen Text.

Weitere Informationen: Was Sie vom benutzerdefinierten IIS7-Fehlermodul erwarten können

Der einfachste Weg, um das Verhalten konsistent zu machen, besteht darin, den Fehler zu löschen und Response.TrySkipIisCustomErrors zu verwenden und auf true zu setzen. Dadurch wird die globale IIS-Fehlerseitenbehandlung innerhalb Ihrer Seite oder der globalen Fehlerbehandlungsroutine in Application_Error überschrieben.

Server.ClearError();
Response.TrySkipIisCustomErrors = true;

Normalerweise sollten Sie dies in Ihrem Application_Error-Handler tun, der alle Fehler behandelt, die Ihre Application Error-Handler nicht abfangen.

Weitere Informationen finden Sie in diesem Blogbeitrag: http://www.west-wind.com/weblog/posts/745738.aspx

Behoben: Es stellt sich heraus, dass "Detaillierte Fehler" aktiviert sein muss, damit IIS7 eine eventuell vorhandene Fehlerseite "durchläuft". Siehe http://forums.iis.net/t/1146653.aspx

Ich bin mir nicht sicher, ob dies von Natur aus ähnlich ist oder nicht, aber ich habe ein Problem gelöst, das an der Oberfläche ähnlich klingt, und hier ist, wie ich damit umgegangen bin.

Zunächst war der Standardwert für existierende Antwort (Auto) in meinem Fall die richtige Antwort, da ich benutzerdefinierte 404, 400 und 500 habe (ich könnte andere erstellen, aber diese drei reichen für meine Arbeit aus). Hier sind die relevanten Abschnitte, die mir geholfen haben.

Aus web.config:

<customErrors mode="Off" />

Und

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/errors/404.aspx" responseMode="ExecuteURL" />
  <error statusCode="500" path="/errors/500.aspx" responseMode="ExecuteURL" />
  <error statusCode="400" path="/errors/400.aspx" responseMode="ExecuteURL" />
</httpErrors>

Von dort habe ich dies in Application_Error auf global.asax hinzugefügt:

    Response.TrySkipIisCustomErrors = True

Auf jeder meiner benutzerdefinierten Fehlerseiten musste ich den richtigen Antwortstatuscode angeben. In meinem Fall verwende ich eine benutzerdefinierte 404, um Benutzer an verschiedene Bereiche meiner Website zu senden. Daher möchte ich keinen 404-Statuscode zurückgeben, es sei denn, es handelt sich tatsächlich um eine tote Seite.

Jedenfalls habe ich es so gemacht. Hoffe das hilft jemandem.

Dieses Problem hat große Kopfschmerzen verursacht. Keiner der zuvor erwähnten Vorschläge allein hat es für mich gelöst, daher schließe ich meine Lösung ein. Für die Aufzeichnung verwendet unsere Umgebung / Plattform:

• .NET Framework 4
• MVC 3
• IIS8 (Workstation) und IIS7 (Webserver)

Insbesondere habe ich versucht, eine HTTP 404-Antwort zu erhalten, die den Benutzer auf unsere benutzerdefinierte 404-Seite umleitet (über die Web.config-Einstellungen).

Zuerst musste mein Code einen werfen HttpException. Die Rückgabe eines NotFoundResultvom Controller hat nicht die gewünschten Ergebnisse erzielt.

throw new HttpException(404, "There is no class with that subject");

Dann musste ich sowohl die customErrorsals auch die httpErrorKnoten in der Web.config konfigurieren.

<customErrors mode="On" defaultRedirect="/classes/Error.aspx">
  <error statusCode="404" redirect="/classes/404.html" />
</customErrors>

...

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
  <clear />
  <error statusCode="404" path="/classes/404.aspx" responseMode="ExecuteURL" />
</httpErrors>

Beachten Sie, dass ich das existingResponseas belassen habe Auto, was sich von der bereitgestellten Lösung @sefl unterscheidet.

Die customErrorsEinstellungen schienen notwendig zu sein, um meine explizit ausgelösten zu verarbeiten HttpException, während der httpErrorsKnoten URLs behandelte, die außerhalb der in Globals.asax.cs angegebenen Routenmuster lagen.

PS Mit diesen Einstellungen musste ich nicht einstellen Response.TrySkipIisCustomErrors

TrySkipIisCustomErrorsist nur ein Teil eines Puzzles. Wenn Sie benutzerdefinierte Fehlerseiten verwenden, aber auch RESTful-Inhalte basierend auf 4xx-Status bereitstellen möchten, liegt ein Problem vor. Das Festlegen der httpErrors.existingResponse von web.config auf "Auto" funktioniert nicht, da .net anscheinend immer einige Seiteninhalte an IIS liefert. Daher führt die Verwendung von "Auto" dazu, dass alle (oder zumindest einige) benutzerdefinierten Fehlerseiten nicht verwendet werden. Die Verwendung von "Ersetzen" funktioniert auch nicht, da die Antwort Ihren http-Statuscode enthält, der Inhalt jedoch leer oder mit einer benutzerdefinierten Fehlerseite gefüllt ist. Und das "PassThrough" schaltet das CEP tatsächlich aus, sodass es nicht verwendet werden kann.

Wenn Sie also CEP in einigen Fällen umgehen möchten (durch Umgehen meine ich, dass Sie den Status 4xx mit einigen Inhalten zurückgeben), benötigen Sie einen zusätzlichen Schritt: Bereinigen Sie den Fehler:

void Application_Error(object sender, EventArgs e)
{
    var httpException = Context.Server.GetLastError() as HttpException;
    var statusCode = httpException != null ? httpException.GetHttpCode() : (int)HttpStatusCode.InternalServerError;

    Context.Server.ClearError();
    Context.Response.StatusCode = statusCode;
}

Wenn Sie also die REST-Antwort (dh 400 - Bad Request) verwenden und Inhalte damit senden möchten, müssen Sie nur TrySkipIisCustomErrorsirgendwo in Aktion festlegen und existingResponseim Abschnitt httpErrors in web.config auf "Auto" setzen. Jetzt:

• Wenn kein Fehler vorliegt (Aktion gibt 4xx oder 5xx zurück) und ein Teil des Inhalts zurückgegeben wird, wird der CEP nicht verwendet und der Inhalt an den Client übergeben.
• Wenn ein Fehler auftritt (eine Ausnahme wird ausgelöst), wird der von den Fehlerbehandlungsroutinen zurückgegebene Inhalt entfernt, sodass der CEP verwendet wird.

Wenn Sie den Status mit leerem Inhalt aus Ihrer Aktion zurückgeben möchten, wird dieser als leere Antwort behandelt und CEP wird angezeigt, sodass dieser Code noch verbessert werden kann.

Standardmäßig verwendet IIS 7 detaillierte benutzerdefinierte Fehlermeldungen, sodass ich davon ausgehen würde, dass Response.StatusCode 404.XX und nicht nur 404 entspricht.

Sie können IIS7 so konfigurieren, dass es die einfacheren Fehlermeldungscodes verwendet, oder Ihren Code ändern, der die detaillierteren Fehlermeldungen behandelt, die IIS7 bietet.

Weitere Informationen finden Sie hier: http://blogs.iis.net/rakkimk/archive/2008/10/03/iis7-enabling-custom-error-pages.aspx

Weitere Untersuchungen ergaben, dass ich es falsch herum hatte - detaillierte Nachrichten sind nicht standardmäßig aktiviert, aber möglicherweise wurden sie auf Ihrer Box aktiviert, wenn Sie die verschiedenen von Ihnen erwähnten Fehlermeldungen sehen.