Ich habe einen heftigen Kopfschmerz vom Versuch, vollständige programmatische Kontrolle über das Rendern eines Fehlers in IIS7 (integrierter Modus) zu bekommen. Was ich tun möchte, ist ein Fehler (Seite nicht gefunden, interner Serverfehler, nicht authentifiziert, etc), übertragen Sie die gesamte Anfrage auf eine benutzerdefinierte ASPX oder HTML (ich bevorzuge letztere) mit dem richtigen HTTP-Status-Code.
Was ich will, ist, dass IIS7 keinen Mist darüber gibt, wofür ich den HTTP-Statuscode eingestellt habe. Ich möchte seine Fehlerbehandlung nicht. Wenn ich Response.StatusCode = (int)HttpStatusCode.NotFound
festlege, möchte ich nicht, dass IIS eine eigene Fehlerseite ausgibt, sondern vielleicht die Anfrage in eine andere Datei übertrage.
Ich habe diese statische Konfiguration zum Laufen gebracht:
%Vor% Während dies funktioniert, gibt es mir bei einem Fehlerszenario keine programmatische Kontrolle darüber, was mit der Antwort zu tun ist. Konfiguration ist ein gutes Fallback, aber ich würde gerne in der Lage sein, Response.StatusCode
zu setzen und unter bestimmten Umständen etwas völlig anderes als das konfigurierte 404.html
darzustellen (wie eine JSON-Antwort, wenn wir Accept: application/json
erhalten), aber IIS7 hat gewonnen Lass mich nicht. Keine Chance.
Also, was soll ich tun? Ich habe versucht, HttpResponse.TrySkipIisCustomErrors Property
zu setzen, aber das sieht so aus ein riesiger Hack und scheint nicht durchgängig zu funktionieren. Setzen Sie diese Eigenschaft wirklich auf die empfohlene Best Practice, um das gewünschte Verhalten zu erhalten?
Im Moment ist das Gefühl, das mir bleibt, nichts anderes als intensiver Hass gegenüber IIS7. Kann mir bitte jemand helfen, dies zu beheben, indem ich beweise, dass ich nur dumm bin und dass ich tatsächlich die volle Kontrolle über den HTTP-Stack haben kann?
Sehen Sie sich Folgendes an: IIS7 Überschreibt customErrors bei der Einstellung von Response.StatusCode ? .
Sie müssen
einstellen %Vor%Tags und Links http iis-7 http-status-codes