這篇文章介紹 Response Caching Middleware .瀏覽器
經過在ASP.NET Core應用中 配置 Response Caching Middleware ,決定何時 response 是能夠緩存,存儲response,和從緩存中提供response 服務。緩存
須要引用的 Microsoft.AspNetCore.App, 或者添加Microsoft.AspNetCore.ResponseCaching包服務器
在Startup.ConfigureServices中,添加中間件到service collection.app
public void ConfigureServices(IServiceCollection services) { services.Configure<CookiePolicyOptions>(options => { options.CheckConsentNeeded = context => true; options.MinimumSameSitePolicy = SameSiteMode.None; }); services.AddResponseCaching(); services.AddMvc() .SetCompatibilityVersion(CompatibilityVersion.Version_2_1); }
配置應用經過UseResponseCaching擴展方法使用中間件,它增長中間件到請求處理管道。async
這個示例應用增長了一個Cache-Control頭到response,應用緩存可緩存的responses長達10秒。工具
示例發送一個Vary頭來配置中間件,提供一個緩存的response,只有當隨後請求的Accept-Encoding頭匹配原始請求的Accept-Encoding. post
在隨後的代碼例子中,CacheControlHeaderValue和HeaderNames要求一個有用狀態,對於MIcrosoft.Net.Http.Headers命名空間。測試
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseCookiePolicy(); app.UseResponseCaching(); app.Use(async (context, next) => { // For GetTypedHeaders, add: using Microsoft.AspNetCore.Http; context.Response.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue() { Public = true, MaxAge = TimeSpan.FromSeconds(10) }; context.Response.Headers[Microsoft.Net.Http.Headers.HeaderNames.Vary] = new string[] { "Accept-Encoding" }; await next(); }); app.UseMvc(); }
Response Caching Middleware僅僅緩存返回的狀態碼爲200的server responses。ui
任何其餘的responses,包括error pages(錯誤頁),都會被中間件忽視。spa
警告:包含認證客戶端的Responses必須被標記爲不可緩存來防止中間件存儲和提供那些響應。
中間件提供了三個options(選項)來控制resonse caching.
下面例子中配置中間件爲:
services.AddResponseCaching(options => { options.UseCaseSensitivePaths = true; options.MaximumBodySize = 1024; });
當使用MVC/Web API控制器或者Razor Pages page models,這些ResponseCache屬性會指定必要的參數,來爲response caching設置合適的頭.
惟一要求中間件的ResponseCache屬性是VaryByQueryKeys, VaryByQueryKeys不會迴應一個真實的HTTP頭。
當不使用ResponseCache屬性時,response caching 能夠隨着VaryByQueryKeys的功能變化。
直接使用來自HttpContext的IFeatureCollection的ResponseCachingFeature :
var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>(); if (responseCachingFeature != null) { responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" }; }
在VaryByQueryKeys中,使用一個等於 * 的單獨的值,會隨着全部request query parameters 而改變cache的值。
Response caching被中間件使用HTTP headers來配置,下面是一些HTTP頭
中間件遵照HTTP 1.1 Caching secification(specification:說明書)的規則。
這些規則要求cache擁有一個被client發送的有效的Cache-Control頭,
在說明書下,一個client能夠發送一個帶no-cache頭值的請求,而且強制服務器爲每一個請求生成一個新的響應。
目前,開發者沒法控制緩存行爲,當使用中間件時;由於中間件依附於官方的緩存說明書。
若是緩存行爲沒按預期進行,確認 響應是可緩存的和緩存提供的功能。
檢查請求進入時的頭部和響應出去時的頭部。容許記錄日誌來幫助調試。
當測試和troubleshooting緩存行爲時,瀏覽器可能會以不合需的方式設置請求頭並影響到緩存。
例如,瀏覽器可能設置Cache-Control頭爲no-cache或者max-age=0當刷新頁面時。下面的工具能夠明確的設置請求頭而且對於測試緩存很受歡迎: