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