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

Question

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

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

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

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

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

В 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> 

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

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

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

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

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

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

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

• 401 - Несанкционированное
• 403 - Запрещенный
• 404 - Not Found
• 405 - Метод не разрешены
• 406 - Не Приемлемый
• 412 - Precondition Failed
• 500 - Внутренний сервер Ошибка
• 501 - Не реализовано
• 502 - Плохой шлюз

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

Answer 1

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

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

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

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

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

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

Чтобы сделать длинную историю короткой, не волнуйтесь :)

Answer 2

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

<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> 

Мои рассуждения заключается в следующем:

• - Контроллеры имеют метод BadRequest() встроенный, и вы можете вернуть это, когда параметр, переданный в действие, недействителен.
• - Применение атрибута Authorize к контроллеру или действию вызывает 401 Несанкционированный отклик. Контроллеры также метод Несанкционированный(), построенный в
• 403,14. - Перенаправление их на 404 Not Found ответов как запрещенный просто неправильно (см Securing your web.config и Troy Hunt's blog для получения дополнительной информации).
• - Брошено, когда пользователь просматривает страницу не найден.
• - Брошено, когда что-то катастрофически неправильно.

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

Here - это полный список кодов состояния ИИС и кодов состояния, которые могут быть полезны для нашей причины. У меня есть ощущение, что 403 Запретный ответ также должен поддерживаться, поскольку он кажется довольно заметным ответом, который был брошен IIS.

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

yoursite/<script></script> 

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

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

Answer 3

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

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

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

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

Answer 4

Там может быть другой путь: это решение использует 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]: ​​Добавить 'Контроллеры/ErrorPageController.cs'

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

[5]: в 'Views/Shared/Error.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