StatusCodePagesMiddleware中間件與ExceptionHandlerMiddleware中間件比較類似，它們都是在後續請求處理過程中“出錯”的情況下利用一個錯誤處理器來完成最終的請求處理與響應的任務。它們之間的差異在於對“錯誤”的界定上，對於ExceptionHandlerMiddleware中間件來說，它所謂的錯誤就是拋出異常，但是對於StatusCodePagesMiddleware中間件來說，則將介於400~599之間的響應狀態碼視為錯誤。如下面的代碼片段所示，StatusCodePagesMiddleware中間件也采用“標准”的定義方式，針對它的配置選項通過一個對應的對象以Options模式的形式提供給它。 [本文已經同步到《ASP.NET Core框架揭秘》之中]
1: public class StatusCodePagesMiddleware
2: {3: public StatusCodePagesMiddleware(RequestDelegate next, IOptions<StatusCodePagesOptions> options);
4: public Task Invoke(HttpContext context);
5: }
除了針對錯誤的界定，StatusCodePagesMiddleware和ExceptionHandlerMiddleware這兩個中間件對於錯誤處理器的表達也不相同。我們知道ExceptionHandlerMiddleware中間件使用的錯誤處理器實際上就是一個類型為RequestDelegate的委托對象，但是錯誤處理器之於StatusCodePagesMiddleware中間件來說則是一個類型為Func<StatusCodeContext, Task>的委托對象。如下面的代碼片段所示，為StatusCodePagesMiddleware中間件提供配置選項的StatusCodePagesOptions對象的唯一目的就是提供這個作為錯誤處理器的委托對象。
1: public class StatusCodePagesOptions
2: { 3: public Func<StatusCodeContext, Task> HandleAsync { get; set; }4: }
我們知道一個RequestDelegate對象相當於一個類型為Func<HttpContext, Task>類型的委托對象，而一個StatusCodeContext對象實際上也是對一個HttpContext對象的封裝，所以StatusCodePagesMiddleware中間件和ExceptionHandlerMiddleware中間件所使采用的錯誤處理器並沒有本質上的不同。如下面的代碼片段所示，除了從StatusCodeContext對象中獲取代表當前請求上下文的HttpContext對象之外，我們還可以通過其Next屬性得到一個RequestDelegate對象，它代表由後續中間件組成的請求處理管道。至於另一個屬性Options，很明顯它返回我們在創建StatusCodePagesMiddleware中間件所指定的StatusCodePagesOptions對象。
1: public class StatusCodeContext
2: { 3: public HttpContext HttpContext { get; } 4: public RequestDelegate Next { get; } 5: public StatusCodePagesOptions Options { get; }6:
7: public StatusCodeContext(HttpContext context, StatusCodePagesOptions options, RequestDelegate next);
8: }
由於采用了針對響應狀態碼的錯誤處理策略，所以實現在StatusCodePagesMiddleware中間件中的所有錯誤處理操作只會發生在當前響應狀態碼在400~599之間的情況，如下所示的代碼片段體現了這一點。從下面給出的代碼片段可以看出，StatusCodePagesMiddleware中間件在決定是否執行錯誤處理操作時除了會查看當前響應狀態碼之外，還會查看響應內容以及媒體類型，如果已經包含了響應內容或者設置了媒體類型，該中間件將不會執行任何操作。
1: public class StatusCodePagesMiddleware
2: {3: private RequestDelegate _next;
4: private StatusCodePagesOptions _options;
5:
6: public StatusCodePagesMiddleware(RequestDelegate next,
7: IOptions<StatusCodePagesOptions> options)
8: {9: _next = next;
10: _options = options.Value;
11: }
12:
13: public async Task Invoke(HttpContext context)
14: { 15: await _next(context);
16: var response = context.Response;
17: if ((response.StatusCode >= 400 && response.StatusCode <= 599) &&!response.ContentLength.HasValue && string.IsNullOrEmpty(response.ContentType))
18: {19: await _options.HandleAsync(new StatusCodeContext(context, _options, _next));
20: }
21: }
22: }
StatusCodePagesMiddleware中間件針對錯誤的處理非常簡單，它只需要從StatusCodePagesOptions對象中提取出作為錯誤處理器的這個Func<StatusCodeContext, Task>對象，然後創建一個StatusCodeContext對象作為輸入參數調用這個委托對象即可。
如果當前響應已經被寫入了內容，或者響應的媒體類型已經被預先設置，那麼StatusCodePagesMiddleware中間件將不會再執行任何的錯誤處理操作。這種情況實際上代表由後續中間件構成的管道可能需要自行控制當前的響應，所以StatusCodePagesMiddleware中間件不應該再做任何的干預。從這個意義上來講，StatusCodePagesMiddleware中間件僅僅是作為一種後備的錯誤處理機制而已。
更進一步來將，如果後續的某個中間件返回了一個狀態碼在400~599之間的響應，並且這個響應只有報頭集合沒有主體（媒體類型自然也不會設置），那麼按照我們在上面給出的錯誤處理邏輯，StatusCodePagesMiddleware中間件還是會按照自己的策略來處理並響應請求。為了解決這種情況下，我們必須賦予後續中間件一個能夠阻止StatusCodePagesMiddleware中間件進行錯誤處理的能力。
阻止StatusCodePagesMiddleware中間件進行錯誤處理的機制是借助於一個名為StatusCodePagesFeature的特性來實現的。StatusCodePagesFeature對應如下這個IStatusCodePagesFeature接口，它具有唯一的布爾類型的屬性成員Enabled。默認使用的StatusCodePagesFeature類型實現了這個接口，默認情況下這個開關是開啟的。
1: public interface IStatusCodePagesFeature
2: { 3: bool Enabled { get; set; }4: }
5:
6: public class StatusCodePagesFeature : IStatusCodePagesFeature
7: { 8: public bool Enabled { get; set; } = true ;9: }
StatusCodePagesMiddleware中間件在將請求交付給後續管道之前，它會創建一個StatusCodePagesFeature特性對象並將其添加到當前HttpContext之中。當最終決定是否執行錯誤處理操作的時候，它還會通過這個特性檢驗是否某個後續的中間件不希望自己“畫蛇添足”地進行不必要的錯誤處理，如下的代碼片段很好的體現了這一點。
1: public class StatusCodePagesMiddleware
2: {3: …
4: public async Task Invoke(HttpContext context)
5: {6: StatusCodePagesFeature feature = new StatusCodePagesFeature();
7: context.Features.Set<IStatusCodePagesFeature>(feature);
8:
9: await _next(context);
10: var response = context.Response;
11: if ((response.StatusCode >= 400 && response.StatusCode <= 599) && !response.ContentLength.HasValue &&string.IsNullOrEmpty(response.ContentType) &&
12: feature.Enabled)
13: {14: await _options.HandleAsync(new StatusCodeContext(context, _options, _next));
15: }
16: }
17: }
我們通過一個簡單的實例來演示如果利用這個StatusCodePagesFeature特性來屏蔽StatusCodePagesMiddleware中間件。在下面這個應用中，我們將針對請求的處理定義在Invoke方法中，該方法會返回一個狀態碼為“401 Unauthorized”的響應。我們通過隨機數讓這個方法會在50%的情況下利用StatusCodePagesFeature特性來阻止StatusCodePagesMiddleware中間件自身對錯誤的處理。我們通過調用擴展方法UseStatusCodePages注冊的StatusCodePagesMiddleware中間件會直接響應一個內容為“Error occurred!”的字符串。
1: public class Program
2: {3: public static void Main()
4: {5: new WebHostBuilder()
6: .UseKestrel()
7: .Configure(app => app
8: .UseStatusCodePages(async context => await context.HttpContext.Response.WriteAsync("Error occurred!"))9: .Run(Invoke))
10: .Build()
11: .Run();
12: }
13:
14: private static Random _random = new Random();
15: private static Task Invoke(HttpContext context)
16: {17: context.Response.StatusCode = 401;
18:
19: if (_random.Next() % 2 == 0)
20: {21: context.Features.Get<IStatusCodePagesFeature>().Enabled = false;
22: }
23: return Task.CompletedTask;
24: }
25: }
對於針對該應用的請求來說，我們會得到如下兩種不同的響應。沒有主體內容響應是通過Invoke方法產生的，這種情況下發生在StatusCodePagesMiddleware中間件通過StatusCodePagesFeature特性被屏蔽的時候。具有主體內容的響應則來源於StatusCodePagesMiddleware中間件。
1: HTTP/1.1 401 Unauthorized
2: Date: Sun, 18 Dec 2016 01:59:37 GMT
3: Server: Kestrel
4: Content-Length: 15
5:
6: Error occurred!
7:
8:
9: HTTP/1.1 401 Unauthorized
10: Date: Sun, 18 Dec 2016 01:59:38 GMT
11: Content-Length: 0
12: Server: Kestrel
我們在大部分情況下都會調用ApplicationBuilder相應的擴展方法來注冊StatusCodePagesMiddleware中間件。對於StatusCodePagesMiddleware中間件的注冊來說，除了我們已經很熟悉的UseStatusCodePages方之外，還具有額外一些擴展方法供我們選擇。
我們可以調用如下三個UseStatusCodePages方法重載來注冊StatusCodePagesMiddleware中間件。不論我們調用那個重載，系統最終都會根據提供的StatusCodePagesOptions對象調用構造函數來創建這個中間件對象，而且這個StatusCodePagesOptions必須具有一個作為錯誤處理器的Func<StatusCodeContext, Task>對象。如果沒有指定任何參數，StatusCodePagesOptions對象需要以Options模式的形式注冊為服務。
1: public static class StatusCodePagesExtensions
2: { 3: public static IApplicationBuilder UseStatusCodePages(this IApplicationBuilder app)
4: { 5: return app.UseMiddleware<StatusCodePagesMiddleware>();
6: }
7:
8: public static IApplicationBuilder UseStatusCodePages(this IApplicationBuilder app, StatusCodePagesOptions options)
9: {10: return app.UseMiddleware<StatusCodePagesMiddleware>(Options.Create(options));
11: }
12:
13: public static IApplicationBuilder UseStatusCodePages(this IApplicationBuilder app, Func<StatusCodeContext, Task> handler)
14: { 15: return app.UseStatusCodePages(new StatusCodePagesOptions
16: {17: HandleAsync = handler
18: });
19: }
20: }
由於StatusCodePagesMiddleware中間件最終的目的還是將定制的錯誤信息響應給客戶端，所以我們可以在注冊該中間件的時候直接指定響應的內容和媒體類型，這樣的注冊方式可以通過調用如下這個UseStatusCodePages方法來完成。從如下所示的代碼片段我們不難看出，我們通過bodyFormat方法指定的實際上是一個模板，它可以包含一個表示響應狀態的占位符（“{0}”）。
1: public static class StatusCodePagesExtensions
2: { 3: public static IApplicationBuilder UseStatusCodePages(this IApplicationBuilder app, string contentType, string bodyFormat)
4: {5: return app.UseStatusCodePages(context =>
6: {7: var body = string.Format(CultureInfo.InvariantCulture, bodyFormat, context.HttpContext.Response.StatusCode);
8: context.HttpContext.Response.ContentType = contentType;
9: return context.HttpContext.Response.WriteAsync(body);
10: });
11: }
12: }
如果我們調用UseStatusCodePagesWithRedirects方法，可以讓注冊的StatusCodePagesMiddleware中間件向指定的路徑發送一個客戶端重定向。從如下所示的實現代碼可以看出，這個作為參數locationFormat的重定向地址也是一個模板，它可以包含一個表示響應狀態的占位符（“{0}”）。我們可以指定一個完整的地址，也可以指定一個相對於PathBase的相對路徑，後者需要包含表示基地址的“~/”前綴。
1: public static class StatusCodePagesExtensions
2: { 3: public static IApplicationBuilder UseStatusCodePagesWithRedirects(this IApplicationBuilder app, string locationFormat)
4: { 5: if (locationFormat.StartsWith("~")) 6: {7: locationFormat = locationFormat.Substring(1);
8: return app.UseStatusCodePages(context =>
9: {10: var location = string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
11: context.HttpContext.Response.Redirect(context.HttpContext.Request.PathBase + location);
12: return Task.CompletedTask;
13: });
14: }
15: else
16: {17: return app.UseStatusCodePages(context =>
18: {19: var location = string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
20: context.HttpContext.Response.Redirect(location);
21: return Task.CompletedTask;
22: });
23: }
24: }
25: }
我們通過一個簡單的應用來演示針對客戶端重定向的錯誤頁面呈現方式。我們在如下這個應用中注冊了一個路由模板為“error/{statuscode}”的路由，路由參數“statuscode”自然代表響應的狀態碼。在作為路由處理器的HandleError方法中，我們會直接響應一個包含響應狀態碼的字符串。我們調用UseStatusCodePagesWithRedirects方法注冊StatusCodePagesMiddleware中間件的時候將重定義路徑設置為“error/{0}”。
1: public class Program
2: {3: private static Random _random = new Random();
4: public static void Main()
5: {6: new WebHostBuilder()
7: .UseKestrel()
8: .ConfigureServices(svcs => svcs.AddRouting())
9: .Configure(app => app
10: .UseStatusCodePagesWithRedirects("~/error/{0}") 11: .UseRouter(builder=>builder.MapRoute("error/{statuscode}", HandleError))12: .Run(context=>Task.Run(()=>context.Response.StatusCode = _random.Next(400,599))))
13: .Build()
14: .Run();
15: }
16:
17: private async static Task HandleError(HttpContext context)
18: {19: var statusCode = context.GetRouteData().Values["statuscode"];
20: await context.Response.WriteAsync($"Error occurred ({statusCode})");21: }
22: }
針對該應用的請求總是會得到一個狀態碼在400~599之間的響應， StatusCodePagesMiddleware在此情況下會向我們指定的路徑（“~/error/{statuscode}”）發送一個客戶端重定向。由於重定向請求的路徑與注冊的路由相匹配，所以作為路由處理器的HandleError方法會響應如圖11所示的這個錯誤頁面。
1: public static class StatusCodePagesExtensions
2: {3: public static IApplicationBuilder UseStatusCodePagesWithReExecute(this IApplicationBuilder app, string pathFormat, string queryFormat = null);
4: }
現在我們對上面演示的這個實例略作修改來演示采服務端重定向呈現出來的錯誤頁面。如下面的代碼片段所示，我們僅僅將針對UseStatusCodePagesWithRedirects方法的調用替換成針對UseStatusCodePagesWithReExecute方法的調用而已。
1: public class Program
2: {3: private static Random _random = new Random();
4: public static void Main()
5: {6: new WebHostBuilder()
7: .UseKestrel()
8: .ConfigureServices(svcs => svcs.AddRouting())
9: .Configure(app => app
10: .UseStatusCodePagesWithReExecute("/error/{0}") 11: .UseRouter(builder=>builder.MapRoute("error/{statuscode}", HandleError))12: .Run(context=>Task.Run(()=>context.Response.StatusCode = _random.Next(400,599))))
13: .Build()
14: .Run();
15: }
16:
17: private async static Task HandleError(HttpContext context)
18: {19: var statusCode = context.GetRouteData().Values["statuscode"];
20: await context.Response.WriteAsync($"Error occurred ({statusCode})");21: }
22: }
對於前面演示的實例，由於錯誤頁面是通過客戶端重定向的方式呈現出來的，所以浏覽器地址欄顯示的是重定向地址。我們在選擇這個實例中采用了服務端重定向，雖然顯示的頁面內容並沒有不同，但是地址欄上的地址是不會發生改變的
1: public static class StatusCodePagesExtensions
2: { 3: public static IApplicationBuilder UseStatusCodePagesWithReExecute(this IApplicationBuilder app,string pathFormat,string queryFormat = null)
4: {5: return app.UseStatusCodePages(async context =>
6: {7: var newPath = new PathString(string.Format(CultureInfo.InvariantCulture, pathFormat, context.HttpContext.Response.StatusCode));
8: var formatedQueryString = queryFormat == null ? null :string.Format(CultureInfo.InvariantCulture, queryFormat, context.HttpContext.Response.StatusCode);
9: context.HttpContext.Request.Path = newPath;
10: context.HttpContext.Request.QueryString = newQueryString;
11: await context.Next(context.HttpContext);
12: });
13: }
14: }
與ExceptionHandlerMiddleware中間價類似，StatusCodePagesMiddleware中間件在處理請求的過程中會改變當前請求上下文的狀態，具體體現在將指定的請求路徑和查詢字符串重新應用到當前請求上下文中。為了不影響前置中間件對請求的正常處理，StatusCodePagesMiddleware中間件在完成自身處理流程之後必須將當前請求上下文恢復到原始的狀態。StatusCodePagesMiddleware中間件依舊是采用一個特性來保存原始的路徑和查詢字符串。這個特性對應的接口為具有如下定義的IStatusCodeReExecuteFeature，令人費解的是該接口僅僅包含兩個針對路徑的屬性，並沒有我們希望的用於攜帶原始查詢上下文的屬性，但是默認實現類型StatusCodeReExecuteFeature包含了這個屬性。
1: public interface IStatusCodeReExecuteFeature
2: { 3: string OriginalPath { get; set; } 4: string OriginalPathBase { get; set; }5: }
6:
7: public class StatusCodeReExecuteFeature : IStatusCodeReExecuteFeature
8: { 9: public string OriginalPath { get; set; } 10: public string OriginalPathBase { get; set; } 11: public string OriginalQueryString { get; set; }12: }
當StatusCodePagesMiddleware中間件在處理異常請求的過程中，在將指定的重定向路徑和查詢字符串應用到當前請求上下文上之前，它會根據原始的上下文創建一個StatusCodeReExecuteFeature特性對象並將其添加到當前HttpContext之上。當整個請求處理過程結束之後，StatusCodePagesMiddleware中間件還會負責將這個特性從當前HttpContext中移除，並恢復原始的請求路徑和查詢字符串。如下所示的代碼片段體現了UseStatusCodePagesWithReExecute方法的真實邏輯。
1: public static class StatusCodePagesExtensions
2: {3: public static IApplicationBuilder UseStatusCodePagesWithReExecute(this IApplicationBuilder app,string pathFormat,string queryFormat = null)
4: { 5: return app.UseStatusCodePages(async context =>
6: {7: var newPath = new PathString(string.Format(CultureInfo.InvariantCulture, pathFormat, context.HttpContext.Response.StatusCode));
8: var formatedQueryString = queryFormat == null ? null :string.Format(CultureInfo.InvariantCulture, queryFormat, context.HttpContext.Response.StatusCode);
9: var newQueryString = queryFormat == null ? QueryString.Empty : new QueryString(formatedQueryString);
10:
11: var originalPath = context.HttpContext.Request.Path;
12: var originalQueryString = context.HttpContext.Request.QueryString;
13:
14: context.HttpContext.Features.Set<IStatusCodeReExecuteFeature>(new StatusCodeReExecuteFeature()
15: {16: OriginalPathBase = context.HttpContext.Request.PathBase.Value,
17: OriginalPath = originalPath.Value,
18: OriginalQueryString = originalQueryString.HasValue ? originalQueryString.Value : null,
19: });
20:
21: context.HttpContext.Request.Path = newPath;
22: context.HttpContext.Request.QueryString = newQueryString;
23: try
24: {25: await context.Next(context.HttpContext);
26: }
27: finally
28: {29: context.HttpContext.Request.QueryString = originalQueryString;
30: context.HttpContext.Request.Path = originalPath;
31: context.HttpContext.Features.Set<IStatusCodeReExecuteFeature>(null);
32: }
33: });
34: }
35: }
ASP.NET Core應用的錯誤處理[1]：三種呈現錯誤頁面的方式
ASP.NET Core應用的錯誤處理[2]：DeveloperExceptionPageMiddleware中間件
ASP.NET Core應用的錯誤處理[3]：ExceptionHandlerMiddleware中間件
ASP.NET Core應用的錯誤處理[4]：StatusCodePagesMiddleware中間件
