这篇文章介绍 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当刷新页面时。下面的工具能够明确的设置请求头而且对于测试缓存很受欢迎: