ASP.NET Custom 404 zwraca 200 OK zamiast 404 Not Found

Miałem podobny problem, chcę pokazać niestandardową stronę jako 404 (czyli ASPX) i działało dobrze na localhost, ale jak tylko zdalny gość połączyłby się, dostaliby ogólne IIS 404.

Rozwiązaniem było dodanie

Response.TrySkipIisCustomErrors = true;

Przed zmianą odpowiedzi.StatusCode.

Znalezione przez Rick Strahl http://www.west-wind.com/weblog/posts/745738.aspx

Rozwiązanie IIS 7 polega na dodaniu tego do swojej sieci.plik konfiguracyjny:

<system.webServer>
  <httpErrors existingResponse="Replace">
    <remove statusCode="500" subStatusCode="-1" />
    <remove statusCode="404" subStatusCode="-1" />
    <error statusCode="404" prefixLanguageFilePath="" path="404.htm" responseMode="File" />
    <error statusCode="500" prefixLanguageFilePath="" path="500.htm" responseMode="File" />
  </httpErrors>
</system.webServer>

Http://forums.asp.net/t/1563128.aspx/1

Spróbuj wywołać odpowiedź.End (), aby pominąć renderowanie...

Response.Status = "404 Not Found";
Response.StatusCode = 404;
Response.End();
return;

Po wielu testach i rozwiązywaniu problemów okazuje się, że niektórzy dostawcy hostingu mogą zakłócać kod zwrotny. Udało mi się to obejść, stosując "hack" w treści.

<%
// This code is required for host that do special 404 handling...
Response.Status = "404 Not Found";
Response.StatusCode = 404;
%>

To pozwoli stronie zwrócić poprawny kod zwrotu bez względu na wszystko.

Udało mi się obejść ten problem, używając poniższej konfiguracji w asp.net webforms za pomocą. NET 3.5.

Zaimplementowany przeze mnie wzorzec omija niestandardowe rozwiązanie przekierowania.NET w sieci.config jak napisałem mój własny do obsługi wszystkich scenariuszy z poprawnym kodem statusu HTTP w nagłówku.

Po pierwsze, sieć.sekcja customErrors config wygląda tak:

<customErrors mode="RemoteOnly" defaultRedirect="~/error.htm" />

Ta konfiguracja zapewnia, że tryb CustomErrors jest ustawiony na on, ustawienie, które będziemy potrzebować później, i zapewnia opcja all-else-fails dla defaultRedirect błędu.htm. Przyda się to, gdy nie mam obsługi konkretnego błędu lub jest coś w rodzaju uszkodzonego połączenia z bazą danych.

Po Drugie, oto globalne zdarzenie błędu asax:

protected void Application_Error(object sender, EventArgs e)
    {
       HandleError();
    }

    private void HandleError()
    {
        var exception = Server.GetLastError();
        if (exception == null) return;

        var baseException = exception.GetBaseException();

        bool errorHandled = _applicationErrorHandler.HandleError(baseException);
        if (!errorHandled) return;


        var lastError = Server.GetLastError();
    if (null != lastError && HttpContext.Current.IsCustomErrorEnabled)
    {
        Elmah.ErrorSignal.FromCurrentContext().Raise(lastError.GetBaseException());
        Server.ClearError();
    }
    }

Ten kod przenosi odpowiedzialność za obsługę błędu na inną klasę. Jeśli błąd nie jest obsługiwany i CustomErrors jest włączony, oznacza to, że mamy sprawę, w której jesteśmy na produkcji i jakoś błąd nikt się tym nie zajął. Wyczyścimy go tutaj, aby użytkownik nie mógł go zobaczyć, ale Zaloguj go w Elmah, abyśmy wiedzieli, co się dzieje.

Klasa applicationErrorHandler wygląda tak:

public bool HandleError(Exception exception)
        {
            if (exception == null) return false;

            var baseException = exception.GetBaseException();

            Elmah.ErrorSignal.FromCurrentContext().Raise(baseException);

            if (!HttpContext.Current.IsCustomErrorEnabled) return false;

            try
            {

                var behavior = _responseBehaviorFactory.GetBehavior(exception);
                if (behavior != null)
                {
                    behavior.ExecuteRedirect();
                    return true;
                }
            }
            catch (Exception ex)
            {
                Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
            }
            return false;
        }

Ta klasa zasadniczo używa wzorca poleceń do zlokalizowania odpowiedniej obsługi błędów dla typu błędu, który został wydany. Ważne jest, aby używać WYJĄTKÓW.GetBaseException () na tym poziomie, ponieważ prawie każdy błąd będzie zawinięty w wyjątek wyższego poziomu. Na przykład, doing "rzuć nowy System.Exception()" z dowolnej strony aspx spowoduje, że na tym poziomie zostanie odebrane HttpUnhandledException, a nie System.Wyjątek.

Kod "fabryczny" jest prosty i wygląda tak:

public ResponseBehaviorFactory()
    {
        _behaviors = new Dictionary<Type, Func<IResponseBehavior>>
                        {
                            {typeof(StoreException), () => new Found302StoreResponseBehavior()},
                            {typeof(HttpUnhandledException), () => new HttpExceptionResponseBehavior()},
                            {typeof(HttpException), () => new HttpExceptionResponseBehavior()},
                            {typeof(Exception), () => new Found302DefaultResponseBehavior()}
                        };
    }

    public IResponseBehavior GetBehavior(Exception exception)
    {                                                                               
        if (exception == null) throw new ArgumentNullException("exception");

        Func<IResponseBehavior> behavior;
        bool tryGetValue = _behaviors.TryGetValue(exception.GetType(), out behavior);

        //default value here:
        if (!tryGetValue)
            _behaviors.TryGetValue(typeof(Exception), out behavior);

        if (behavior == null)
            Elmah.ErrorSignal.FromCurrentContext().Raise(
                new Exception(
                    "Danger! No Behavior defined for this Exception, therefore the user might have received a yellow screen of death!",
                    exception));
        return behavior();
    }

W końcu mam rozszerzalny schemat obsługi błędów. W każdym z zdefiniowanych "zachowań" mam niestandardową implementację dla typu błędu. Na przykład wyjątek Http będzie sprawdzany pod kątem kodu stanu i odpowiednio obsługiwany. A 404 status kod będzie wymagał serwera.Przelew zamiast wniosku.Przekierowanie, wraz z odpowiednim kodem stanu zapisanym w nagłówku.