MVC 错误处理要涵盖哪些 HTTP 状态代码

Which HTTP Status Codes to cover for MVC error handling

我目前正在我的 MVC 应用程序的错误处理代码中开发自定义错误页面。但我不清楚要涵盖哪些 HTTP 状态代码。

问题:是否有应满足的典型 HTTP 状态代码列表?

很多文章解释了如何进行 MVC 错误处理和自定义错误页面,但似乎只在其错误处理代码中显示了几个 HTTP 状态代码:403、404 和 500。以 HTTP Status Code: 408 为例呢?这应该被覆盖吗?其他状态代码吨 - HTTP status codes on wiki

这听起来像是一个愚蠢的问题,但我真的不知道答案,也找不到这方面的信息。我在这里是否遗漏了什么,即应该只涵盖状态代码的子集吗?

如果有帮助,下面是我为 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

2015 年 11 月 2 日的进一步调查结果

我刚刚发现的东西一直在盯着我看,而我却错过了...在 IIS 中,涵盖的默认错误页面是:

如果这是 Microsoft 设置的良好范围,那么我将以此为指导前进!

一个有趣的问题,恕我直言。

这三个错误(403、404 和 500)是真实用户使用标准浏览器访问您的网站时可能发生的最常见错误。

另一方面,HTTP 标准是为服务器和代理开发人员编写的,目的是定义双方的操作方式。自然地,像 IE、Chrome、Firefox 等标准浏览器以及像 Google 或 Bing 机器人这样的标准机器人正确地满足了要求,但是一些专有的书面代理可能会发送一个格式错误的请求,并且标准提供了服务器在这种情况下应该发送的一组代码。例如,如果缺少 Content-Length 字段,服务器 returns 错误代码 411。但是,您不应该为这种情况提供用户友好的页面。

代码408(请求超时)在标准中解释如下:

"The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time."

而且您也不应为其制作用户友好的页面。

长话短说,别担心:)

我也在寻找答案。我的代码看起来很像你的。这是一个很好的问题,观点很少,我已经为这个问题设置了赏金。到目前为止,我自己已经处理了以下代码:

<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() 方法,当传递给操作的参数无效时,您可能希望 return 使用此方法。
  • 401 - 将授权属性应用于控制器或操作会导致 401 未授权响应。控制器还内置了 Unauthorized() 方法。
  • 403.14 - 将这些重定向到 404 Not Found 响应,因为禁止是完全错误的(有关更多信息,请参阅 Securing your web.config and Troy Hunt's blog)。
  • 404 - 当用户浏览到未找到的页面时抛出。
  • 500 - 当发生灾难性错误时抛出。

总的来说,我觉得你应该处理那些你自己将要使用的代码。问题是 IIS 会做各种奇怪的事情,我们需要处理其中一些不正确或无效的响应,例如我上面列出的 403.14。

Here 是 IIS HTTP 状态代码和子状态代码的完整列表,可能对我们的事业有用。我感觉 403 Forbidden 响应也应该得到支持,因为它似乎是 IIS 抛出的一个相当突出的响应。

我在谷歌搜索时发现的一件有趣的事情是导航到:

yoursite/<script></script>

Returns 来自 IIS 的 500 内部服务器。我觉得这应该 return 一个 404。IIS 错误页面没有告诉我们子状态代码是什么,我很想知道我们如何找到,以便我们可以重定向 500.Something 到 404 Not Found 页面。

Here 是 ASP.NET MVC 样板项目的 GitHub 页面的 link,我正在为此进行研究,您可以在哪里查看我的代码。

不要过分依赖 http 状态代码。

在过去的几年里,我曾与一些糟糕的网络开发人员合作过,他们在他们的回复中错误地使用了它们。

我可能会寻找 200-299 内的代码来表示成功。 我可能会查找代码 >500 以指示服务器故障。

除此之外,我使用了一种自私的方法,即如果您提出请求,希望将数据包返回给您,那么请检查数据。如果没有数据或数据不正确,那么我肯定知道有问题,因为我没有得到我需要的东西以名义上的方式继续 运行 我的应用程序。

可能还有另一种方法:此解决方案使用 1 个自定义错误页面来处理所有类型(我认为?)

[1]:从 Web.config

中删除所有 'customErrors' & 'httpErrors'

[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]: 在 '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