Какие коды состояния HTTP для покрытия ошибок MVC

В настоящее время я разрабатываю пользовательские страницы ошибок в своем коде обработки ошибок для моего приложения MVC. Но я не понимаю, какие коды состояния HTTP я должен покрыть.

Вопрос: существует ли типичный список кодов состояния HTTP, на которые нужно обслуживать?

В нескольких статьях, в которых объясняется, как обрабатывать ошибки MVC и страницы пользовательских ошибок, но, похоже, отображает только несколько кодов состояния HTTP: 403, 404 и 500 в коде обработки ошибок. Что относительно кода статуса HTTP: 408 в качестве примера? Должно ли это быть охвачено? Что относительно тонны других кодов состояния - Коды состояния HTTP на вики

Это может показаться глупым вопросом, но я действительно не знаю ответа и не могу найти информацию об этом. Я что-то пропустил здесь, т.е. Должен ли покрываться только подмножество кодов состояния?

Если это поможет, ниже - это то, что я сделал для обработки ошибок MVC. Этот код (до сих пор с небольшим тестированием, который я сделал) охватывает 404 и все исключения 50x типов:

1 В файле web.config и записи для каждого кода состояния HTTP я хочу использовать

<httpErrors errorMode="Custom" existingResponse="Replace" >
  <remove statusCode="403" />
  <remove statusCode="404" />
  <remove statusCode="500" />
  <error statusCode="403" responseMode="ExecuteURL" path="/Error/Forbidden" />
  <error statusCode="404" responseMode="ExecuteURL" path="/Error/NotFound" />
  <error statusCode="500" responseMode="ExecuteURL" path="/Error" />
</httpErrors>  

2 Контроллер ошибок

    namespace MyApp.Controllers
    {
      public class ErrorController : Controller
      {
      public ActionResult Index()
      {
        return View();
      }
      public ActionResult Forbidden()
      {
        return View();
      }
      public ActionResult NotFound()
      {
        return View();
      }

3 Удобные страницы с ошибками:

/Views/Shared/Index.cshtml
/Views/Shared/Forbidden.cshtml
/Views/Shared/NotFound.cshtml

4 ELMAH для регистрации

Дальнейшие выводы на 2 ноября 2015 г.

Что-то, что я только что обнаружил, что смотрел на меня в лицо, которое я пропустил... В IIS страницы с ошибками по умолчанию:

  • 401 - Несанкционированный
  • 403 - Запрещено
  • 404 - Не найдено
  • 405 - метод не разрешен
  • 406 - Не допускается
  • 412 - Сбой предварительного условия
  • 500 - Внутренняя ошибка сервера
  • 501 - не реализовано
  • 502 - Bad Gateway

Если это хороший диапазон, который Microsoft установила, я пойду по этому пути в качестве руководства, идущего вперед!

Ответ 1

Интересный вопрос, ИМХО.

Эти три ошибки (403, 404 и 500) являются наиболее распространенными ошибками, которые могут произойти с реальным пользователем, обращающимся к вашему сайту со стандартным браузером.

С другой стороны, стандарт HTTP был написан как для разработчиков серверов, так и для агентов, чтобы определить, как обе стороны должны работать. Естественно, что стандартные браузеры, такие как IE, Chrome, Firefox и т.д., А также стандартные роботы, такие как Google или Bing, правильно выполняют требования, но некоторые запатентованные письменные агенты могут отправлять искаженный запрос, а стандарт предоставляет набор кодов сервер должен отправить эту ситуацию. Например, если поле Content-Length пропущено, сервер возвращает код ошибки 411. Однако вы не должны предоставлять удобные для пользователя страницы для такой ситуации.

Код 408 (Тайм-аут запроса) объясняется в стандарте следующим образом:

"Клиент не выдал запрос в течение времени, когда сервер был готов ждать. Клиент МОЖЕТ повторить запрос без изменений в любое другое время".

и это также не случай, для которого вы должны сделать удобную для пользователя страницу.

Короче говоря, не волнуйтесь:)

Ответ 2

Может быть другой способ: это решение использует 1 страницу пользовательской ошибки для обработки всех типов (я думаю?)

[1]: удалить все "customErrors" и "httpErrors" из Web.config

[2]: Проверить 'App_Start/FilterConfig.cs' выглядит так:

public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());
    }
}

[3]: в 'Global.asax' добавьте этот метод:

public void Application_Error(Object sender, EventArgs e)
{
    Exception exception = Server.GetLastError();
    Server.ClearError();

    var routeData = new RouteData();
    routeData.Values.Add("controller", "ErrorPage");
    routeData.Values.Add("action", "Error");
    routeData.Values.Add("exception", exception);

    if (exception.GetType() == typeof(HttpException))
    {
        routeData.Values.Add("statusCode", ((HttpException)exception).GetHttpCode());
    }
    else
    {
        routeData.Values.Add("statusCode", 500);
    }

    Response.TrySkipIisCustomErrors = true;
    IController controller = new ErrorPageController();
    controller.Execute(new RequestContext(new HttpContextWrapper(Context), routeData));
    Response.End();
}

[4]: ​​Добавить 'Controllers/ErrorPageController.cs'

public class ErrorPageController : Controller
{
    public ActionResult Error(int statusCode, Exception exception)
    {
         Response.StatusCode = statusCode;
         ViewBag.StatusCode = statusCode + " Error";
         return View();
    }
}

[5]: в разделе "Просмотры/Общие/Ошибка .cshtml"

@model System.Web.Mvc.HandleErrorInfo
@{
    ViewBag.Title = (!String.IsNullOrEmpty(ViewBag.StatusCode)) ? ViewBag.StatusCode : "500 Error";
}

<h1 class="error">@(!String.IsNullOrEmpty(ViewBag.StatusCode) ? ViewBag.StatusCode : "500 Error"):</h1>

//@Model.ActionName
//@Model.ContollerName
//@Model.Exception.Message
//@Model.Exception.StackTrace

Ответ 3

Я также пытаюсь выяснить ответ. Мой код выглядит так же, как ваш. Это большой вопрос с таким количеством просмотров, я поставил щедрость на этот вопрос. До сих пор я сам обрабатывал следующие коды:

<system.webServer>
  <!-- Custom error pages -->
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <!-- Redirect IIS 400 Bad Request responses to the error controllers bad request action. -->
    <remove statusCode="400" />
    <error statusCode="400" responseMode="ExecuteURL" path="/error/badrequest" />
    <!-- Redirect IIS 401 Unauthorized responses to the error controllers unauthorized action. -->
    <remove statusCode="401" />
    <error statusCode="401" responseMode="ExecuteURL" path="/error/unauthorized" />
    <!-- Redirect IIS 403.14 Forbidden responses to the error controllers not found action. 
         A 403.14 happens when navigating to an empty folder like /Content and directory browsing is turned off
         See http://rehansaeed.co.uk/securing-the-aspnet-mvc-web-config/ and http://www.troyhunt.com/2014/09/solving-tyranny-of-http-403-responses.html -->
    <error statusCode="403" subStatusCode="14" responseMode="ExecuteURL" path="/error/notfound" />
    <!-- Redirect IIS 404 Not Found responses to the error controllers not found action. -->
    <remove statusCode="404" />
    <error statusCode="404" responseMode="ExecuteURL" path="/error/notfound" />
    <!-- Redirect IIS 500 Internal Server Error responses to the error controllers internal server error action. -->
    <remove statusCode="500" />
    <error statusCode="500" responseMode="ExecuteURL" path="/error" />
  </httpErrors>
</system.webServer>

Мое рассуждение таково:

  • 400. - Контроллеры имеют встроенный метод BadRequest(), и вы можете вернуть его, когда параметр, переданный действию, недействителен.
  • 401. Применение атрибута Authorize к контроллеру или действию вызывает 401 Несанкционированный отклик. Контроллеры также имеют встроенный метод Unauthorized().
  • 403.14. Перенаправить их на 404 Не найденные ответы как Запрещенные просто неправильно (см. Защита вашего web.config и блог Троя Хант для получения дополнительной информации).
  • 404 - брошен, когда пользователь просматривает страницу, не найденную.
  • 500 - брошен, когда что-то катастрофически неправильно.

В целом я чувствую, что вы должны обрабатывать те коды, которые вы сами собираетесь использовать. Проблема в том, что IIS выполняет всевозможные странные вещи, и нам нужно обрабатывать некоторые из них неправильные или недействительные ответы, такие как приведенный выше список 403.14.

Здесь - полный список кодов состояния IIS и кодов состояния, которые могут быть полезны для нашей причины. Я чувствую, что 403 Forbidden ответ также должен поддерживаться, поскольку он кажется довольно заметным ответом, выданным IIS.

Одна интересная вещь, которую я обнаружил, в то время как Googling - это переход на:

yoursite/<script></script>

Возвращает 500 внутренних серверов из IIS. Я чувствую, что это должно вернуть 404. Страница ошибок IIS не сообщает нам, что такое код под-состояния, и мне было бы интересно узнать, как мы можем это выяснить, чтобы мы могли перенаправить 500.Что-то на 404 не найдено стр.

Здесь - ссылка на страницу GitHub для проекта ASP.NET MVC Boilerplate, для которой я занимаюсь этим исследованием, и где вы можете посмотрите мой код.

Ответ 4

Не слишком полагайтесь на коды статуса http.

За последние пару лет я работал с несколькими плохими веб-разработчиками, которые неправильно использовали их в своих ответах.

Я могу искать коды в течение 200-299 для подтверждения успеха. Я могу найти коды > 500, чтобы указать на сбой сервера.

Кроме того, я использую эгоистичный подход, т.е. если вы делаете запрос о том, что вы ожидаете получить пакет данных, возвращаемых вам, а затем проверьте данные. Если нет данных или если данные плохие, то я точно знаю, что возникла проблема, потому что я не получил то, что мне нужно, чтобы продолжить выполнение моего приложения номинальным способом.