Middleware pro ukládání odpovědí do mezipaměti v ASP.NET Core
John Luo a Rick Anderson
Tento článek vysvětluje, jak nakonfigurovat middleware pro ukládání odpovědí do mezipaměti v aplikaci ASP.NET Core. Middleware určuje, kdy se odpovědi dají ukládat do mezipaměti, ukládají odpovědi a obsluhují odpovědi z mezipaměti. Úvod do mezipaměti HTTP a [ResponseCache]
atributu najdete v tématu Ukládání odpovědí do mezipaměti.
Middleware pro ukládání odpovědí do mezipaměti:
- Umožňuje ukládání odpovědí serveru do mezipaměti na základě hlaviček mezipaměti HTTP. Implementuje standardní sémantiku ukládání do mezipaměti HTTP. Mezipaměti založené na hlavičkách mezipaměti HTTP, jako jsou proxy servery.
- Aplikace uživatelského rozhraní, jako Razor jsou stránky, obvykle nejsou užitečné, protože prohlížeče obvykle nastavují hlavičky požadavků, které brání ukládání do mezipaměti. Ukládání výstupu do mezipaměti, které je dostupné v ASP.NET Core 7.0 a novějších, přináší výhody aplikací uživatelského rozhraní. Při ukládání výstupu do mezipaměti se konfigurace rozhodne, co se má ukládat do mezipaměti nezávisle na hlavičkách HTTP.
- Může být přínosné pro veřejné požadavky rozhraní GET nebo HEAD API od klientů, u kterých jsou splněny podmínky pro ukládání do mezipaměti .
Pokud chcete otestovat ukládání odpovědí do mezipaměti, použijte Fiddler nebo jiný nástroj, který může explicitně nastavit hlavičky požadavků. Pro testování ukládání do mezipaměti se explicitně upřednostňuje nastavení hlaviček. Další informace naleznete v tématu Poradce při potížích.
Konfigurace
Do Program.cs
kolekce služby přidejte služby AddResponseCaching Middleware pro ukládání odpovědí do mezipaměti a nakonfigurujte aplikaci tak, aby používala middleware s metodou UseResponseCaching rozšíření. UseResponseCaching
přidá middleware do kanálu zpracování požadavků:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCaching();
var app = builder.Build();
app.UseHttpsRedirection();
// UseCors must be called before UseResponseCaching
//app.UseCors();
app.UseResponseCaching();
Upozorňující
UseCors musí být volána před UseResponseCaching použitím middlewaru CORS.
Ukázková aplikace přidá hlavičky pro řízení ukládání do mezipaměti při následných požadavcích:
- Řízení mezipaměti: Ukládá odpovědi do mezipaměti po dobu až 10 sekund.
- Vary: Nakonfiguruje middleware tak, aby obsluhoval odpověď uloženou v mezipaměti pouze v případě, že hlavička Accept-Encoding následných požadavků odpovídá hlavičce původního požadavku.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCaching();
var app = builder.Build();
app.UseHttpsRedirection();
// UseCors must be called before UseResponseCaching
//app.UseCors();
app.UseResponseCaching();
app.Use(async (context, next) =>
{
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.MapGet("/", () => DateTime.Now.Millisecond);
app.Run();
Předchozí hlavičky nejsou zapsány do odpovědi a jsou přepsány při kontroleru, akci nebo Razor stránce:
- Má atribut [ResponseCache]. To platí i v případě, že vlastnost není nastavená. Například vynechání vlastnosti VaryByHeader způsobí odebrání odpovídající hlavičky z odpovědi.
Middleware ukládání odpovědí do mezipaměti ukládá pouze odpovědi serveru, které mají za následek stavový kód 200 (OK). Middleware ignoruje všechny ostatní odpovědi, včetně chybových stránek.
Upozorňující
Odpovědi obsahující obsah pro ověřené klienty musí být označeny jako neukládatelné do mezipaměti, aby se zabránilo ukládání a obsluhování těchto odpovědí middlewarem. Podrobnosti o tom, jak middleware určuje, jestli je odpověď uložená v mezipaměti, najdete v tématu Podmínky pro ukládání do mezipaměti .
Předchozí kód obvykle nevrací hodnotu uloženou v mezipaměti do prohlížeče. Použijte Fiddler nebo jiný nástroj, který může explicitně nastavit hlavičky požadavků a preferuje se pro testování ukládání do mezipaměti. Další informace najdete v tématu Řešení potíží v tomto článku.
Možnosti
Možnosti ukládání odpovědí do mezipaměti jsou uvedené v následující tabulce.
Možnost | Popis |
---|---|
MaximumBodySize | Největší velikost uložená v mezipaměti textu odpovědi v bajtech. Výchozí hodnota je 64 * 1024 * 1024 (64 MB). |
SizeLimit | Omezení velikosti middlewaru mezipaměti odpovědí v bajtech. Výchozí hodnota je 100 * 1024 * 1024 (100 MB). |
UseCaseSensitivePaths | Určuje, jestli jsou odpovědi uloženy v mezipaměti na cestách s rozlišováním velkých a malých písmen. Výchozí hodnota je false . |
Následující příklad nakonfiguruje middleware na:
- Ukládat odpovědi do mezipaměti s velikostí těla menší nebo rovnou 1 024 bajtům
- Uložte odpovědi podle cest citlivých na malá a velká písmena. Například
/page1
jsou/Page1
uloženy samostatně.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCaching(options =>
{
options.MaximumBodySize = 1024;
options.UseCaseSensitivePaths = true;
});
var app = builder.Build();
app.UseHttpsRedirection();
// UseCors must be called before UseResponseCaching
//app.UseCors();
app.UseResponseCaching();
app.Use(async (context, next) =>
{
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(context);
});
app.MapGet("/", () => DateTime.Now.Millisecond);
app.Run();
VaryByQueryKeys
Při použití MVC, kontrolerů webového rozhraní API nebo Razor stránkovacích modelů [ResponseCache]
stránky určuje atribut parametry nezbytné pro nastavení příslušných hlaviček pro ukládání odpovědí do mezipaměti. Jediný parametr atributu [ResponseCache]
, který striktně vyžaduje middleware , VaryByQueryKeyskterý neodpovídá skutečné hlavičce HTTP. Další informace najdete v tématu Ukládání odpovědí do mezipaměti v ASP.NET Core.
Pokud atribut nepoužíváte [ResponseCache]
, ukládání odpovědí do mezipaměti se může lišit pomocí VaryByQueryKeys
. ResponseCachingFeature Použijte přímo z httpContext.Features:
var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();
if (responseCachingFeature != null)
{
responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}
Použití jedné hodnoty, která *
se rovná hodnotě, VaryByQueryKeys
se liší mezi mezipamětí podle všech parametrů dotazu požadavku.
Hlavičky HTTP používané middlewarem ukládání odpovědí do mezipaměti
Následující tabulka obsahuje informace o hlavičkách HTTP, které ovlivňují ukládání odpovědí do mezipaměti.
Hlavička | Detaily |
---|---|
Authorization |
Odpověď není uložená v mezipaměti, pokud hlavička existuje. |
Cache-Control |
Middleware bere v úvahu pouze odpovědi na ukládání do mezipaměti označené direktivou public cache. Řízení ukládání do mezipaměti pomocí následujících parametrů:
max-stale žádný limit , middleware nebude provádět žádnou akci.– proxy-revalidate má stejný účinek jako must-revalidate .Další informace naleznete v dokumentu RFC 9111: Direktivy požadavků. |
Pragma |
Hlavička Pragma: no-cache v požadavku vytvoří stejný účinek jako Cache-Control: no-cache . Tato hlavička je přepsána příslušnými direktivy v Cache-Control hlavičce, pokud je k dispozici. Zvažte zpětnou kompatibilitu s protokolem HTTP/1.0. |
Set-Cookie |
Odpověď není uložená v mezipaměti, pokud hlavička existuje. Jakýkoli middleware v kanálu zpracování požadavků, který nastaví jeden nebo více souborů cookie, zabraňuje middlewaru ukládání odpovědí do mezipaměti v ukládání odpovědi do mezipaměti (například cookieposkytovatel TempData založený na -based TempData). |
Vary |
Hlavička Vary se používá k různým odpovědím uloženým v mezipaměti podle jiné hlavičky. Například odpovědi mezipaměti kódováním zahrnutím hlavičky Vary: Accept-Encoding do mezipaměti, která ukládá odpovědi na požadavky s hlavičkami Accept-Encoding: gzip a Accept-Encoding: text/plain samostatně. Odpověď s hodnotou * hlavičky se nikdy neuloží. |
Expires |
Odpověď považována za zastaralou touto hlavičkou není uložená nebo načtená, pokud ji nepřepíše jiná Cache-Control hlavička. |
If-None-Match |
Úplná odpověď se obsluhuje z mezipaměti, pokud hodnota * není a ETag odpověď neodpovídá žádné zadané hodnotě. Jinak se obsluhuje odpověď 304 (Neupraveno). |
If-Modified-Since |
Pokud hlavička If-None-Match není k dispozici, úplná odpověď se obsluhuje z mezipaměti, pokud je datum odpovědi uložené v mezipaměti novější než zadaná hodnota. Jinak se obsluhuje odpověď 304 – Neupravená. |
Date |
Při poskytování z mezipaměti je hlavička nastavena middlewarem, Date pokud nebyla k dispozici v původní odpovědi. |
Content-Length |
Při poskytování z mezipaměti je hlavička nastavena middlewarem, Content-Length pokud nebyla k dispozici v původní odpovědi. |
Age |
Hlavička Age odeslaná v původní odpovědi se ignoruje. Middleware vypočítá novou hodnotu při poskytování odpovědi uložené v mezipaměti. |
Ukládání do mezipaměti respektuje direktivy Cache-Control
Middleware respektuje pravidla RFC 9111: Ukládání do mezipaměti HTTP (oddíl 5.2. Řízení mezipaměti). Pravidla vyžadují, aby byla v mezipaměti dodržena platná Cache-Control
hlavička odeslaná klientem. V rámci specifikace může klient vyžadovat požadavky s no-cache
hodnotou hlavičky a vynutit, aby server vygeneroval novou odpověď pro každý požadavek. V současné době neexistuje žádná kontrola nad tímto chováním při ukládání do mezipaměti při použití middlewaru, protože middleware dodržuje oficiální specifikaci ukládání do mezipaměti.
Pokud chcete mít větší kontrolu nad chováním při ukládání do mezipaměti, prozkoumejte další funkce ukládání do mezipaměti ASP.NET Core. Viz následující témata:
- Ukládání do mezipaměti v paměti v ASP.NET Core
- Distribuované ukládání do mezipaměti v ASP.NET Core
- Pomocná rutina značek mezipaměti v ASP.NET Core MVC
- Pomocná rutina značek distribuované mezipaměti v ASP.NET Core
Řešení problému
Middleware ukládání odpovědí do mezipaměti používá IMemoryCache, který má omezenou kapacitu. Při překročení kapacity se zkomprimuje mezipaměť paměti.
Pokud chování při ukládání do mezipaměti neodpovídá očekávání, ověřte, že odpovědi jsou uložené v mezipaměti a že je možné je obsluhovat z mezipaměti. Zkontrolujte příchozí hlavičky požadavku a odchozí hlavičky odpovědi. Povolte protokolování , které vám pomůže s laděním.
Při testování a řešení potíží s chováním ukládání do mezipaměti prohlížeč obvykle nastaví hlavičky požadavků, které brání ukládání do mezipaměti. Například prohlížeč může záhlaví nastavit Cache-Control
na no-cache
nebo max-age=0
při aktualizaci stránky. Fiddler a další nástroje můžou explicitně nastavit hlavičky požadavků a preferují se pro testování ukládání do mezipaměti.
Podmínky ukládání do mezipaměti
- Požadavek musí mít za následek odpověď serveru se stavovým kódem 200 (OK).
- Metoda požadavku musí být GET nebo HEAD.
- Middleware pro ukládání odpovědí do mezipaměti musí být umístěn před middlewarem, který vyžaduje ukládání do mezipaměti. Další informace najdete v tématu Middleware ASP.NET Core.
- Záhlaví
Authorization
nesmí být přítomno. Cache-Control
parametry hlavičky musí být platné a odpověď musí být označenapublic
a nesmí být označenaprivate
.- Záhlaví
Pragma: no-cache
nesmí být přítomno, pokudCache-Control
záhlaví není k dispozici, protožeCache-Control
záhlaví přepíše hlavičkuPragma
, když je k dispozici. - Záhlaví
Set-Cookie
nesmí být přítomno. Vary
parametry hlavičky musí být platné a nerovnají se*
.- Hodnota
Content-Length
hlavičky (pokud je nastavená) se musí shodovat s velikostí textu odpovědi. - Nepoužívá IHttpSendFileFeature se.
- Odpověď nesmí být zastaralá, jak je uvedeno v
Expires
hlavičce a direktiváchmax-age
mezipamětis-maxage
. - Ukládání odpovědí do vyrovnávací paměti musí být úspěšné. Velikost odpovědi musí být menší než nakonfigurovaná nebo výchozí SizeLimithodnota . Velikost těla odpovědi musí být menší než nakonfigurovaná nebo výchozí MaximumBodySizehodnota .
- Odpověď musí být uložená v mezipaměti podle dokumentu RFC 9111: Ukládání do mezipaměti HTTP. Například direktiva
no-store
nesmí existovat v polích hlavičky požadavku nebo odpovědi. Podrobnosti najdete v dokumentu RFC 9111: Ukládání odpovědí do mezipaměti http (oddíl 3: Ukládání odpovědí do mezipaměti .
Poznámka:
Antiforgery systém pro generování zabezpečených tokenů, aby se zabránilo útokům CSRF (Cross-Site Request Forgery), nastaví Cache-Control
a Pragma
hlavičky tak no-cache
, aby odpovědi nejsou uložené v mezipaměti. Informace o tom, jak zakázat antiforgery tokeny pro elementy formuláře HTML, naleznete v tématu Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core.
Další materiály
- Zobrazení nebo stažení ukázkového kódu (postup stažení)
- Zdroj GitHubu pro
IResponseCachingPolicyProvider
- Zdroj GitHubu pro
IResponseCachingPolicyProvider
- Spuštění aplikace v ASP.NET Core
- ASP.NET Core Middleware
- Ukládání do mezipaměti v paměti v ASP.NET Core
- Distribuované ukládání do mezipaměti v ASP.NET Core
- Detekce změn pomocí tokenů změn v ASP.NET Core
- Ukládání odpovědí do mezipaměti v ASP.NET Core
- Pomocná rutina značek mezipaměti v ASP.NET Core MVC
- Pomocná rutina značek distribuované mezipaměti v ASP.NET Core
Tento článek vysvětluje, jak nakonfigurovat middleware pro ukládání odpovědí do mezipaměti v aplikaci ASP.NET Core. Middleware určuje, kdy se odpovědi dají ukládat do mezipaměti, ukládají odpovědi a obsluhují odpovědi z mezipaměti. Úvod do mezipaměti HTTP a [ResponseCache]
atributu najdete v tématu Ukládání odpovědí do mezipaměti.
Zobrazení nebo stažení ukázkového kódu (postup stažení)
Konfigurace
Middleware pro ukládání odpovědí do mezipaměti je implicitně dostupný pro aplikace ASP.NET Core prostřednictvím sdílené architektury.
Do Startup.ConfigureServices
kolekce služby přidejte middleware pro ukládání odpovědí do mezipaměti:
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddRazorPages();
}
Nakonfigurujte aplikaci tak, aby používala middleware s UseResponseCaching rozšiřující metodou, která přidává middleware do kanálu zpracování požadavků v Startup.Configure
:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
}
app.UseStaticFiles();
app.UseRouting();
// UseCors must be called before UseResponseCaching
// app.UseCors("myAllowSpecificOrigins");
app.UseResponseCaching();
app.Use(async (context, next) =>
{
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.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
}
Upozorňující
UseCors musí být volána před UseResponseCaching použitím middlewaru CORS.
Ukázková aplikace přidá hlavičky pro řízení ukládání do mezipaměti při následných požadavcích:
- Řízení mezipaměti: Ukládá odpovědi do mezipaměti po dobu až 10 sekund.
- Vary: Nakonfiguruje middleware tak, aby obsluhoval odpověď uloženou v mezipaměti pouze v případě, že hlavička Accept-Encoding následných požadavků odpovídá hlavičce původního požadavku.
// using Microsoft.AspNetCore.Http;
app.Use(async (context, next) =>
{
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();
});
Předchozí hlavičky nejsou zapsány do odpovědi a jsou přepsány při kontroleru, akci nebo Razor stránce:
- Má atribut [ResponseCache]. To platí i v případě, že vlastnost není nastavená. Například vynechání vlastnosti VaryByHeader způsobí odebrání odpovídající hlavičky z odpovědi.
Middleware ukládání odpovědí do mezipaměti ukládá pouze odpovědi serveru, které mají za následek stavový kód 200 (OK). Middleware ignoruje všechny ostatní odpovědi, včetně chybových stránek.
Upozorňující
Odpovědi obsahující obsah pro ověřené klienty musí být označeny jako neukládatelné do mezipaměti, aby se zabránilo ukládání a obsluhování těchto odpovědí middlewarem. Podrobnosti o tom, jak middleware určuje, jestli je odpověď uložená v mezipaměti, najdete v tématu Podmínky pro ukládání do mezipaměti .
Možnosti
Možnosti ukládání odpovědí do mezipaměti jsou uvedené v následující tabulce.
Možnost | Popis |
---|---|
MaximumBodySize | Největší velikost uložená v mezipaměti textu odpovědi v bajtech. Výchozí hodnota je 64 * 1024 * 1024 (64 MB). |
SizeLimit | Omezení velikosti middlewaru mezipaměti odpovědí v bajtech. Výchozí hodnota je 100 * 1024 * 1024 (100 MB). |
UseCaseSensitivePaths | Určuje, jestli jsou odpovědi uloženy v mezipaměti na cestách s rozlišováním velkých a malých písmen. Výchozí hodnota je false . |
Následující příklad nakonfiguruje middleware na:
- Ukládat odpovědi do mezipaměti s velikostí těla menší nebo rovnou 1 024 bajtům
- Uložte odpovědi podle cest citlivých na malá a velká písmena. Například
/page1
jsou/Page1
uloženy samostatně.
services.AddResponseCaching(options =>
{
options.MaximumBodySize = 1024;
options.UseCaseSensitivePaths = true;
});
VaryByQueryKeys
Při použití řadičů MVC / webových rozhraní API nebo Razor modelů [ResponseCache]
stránek stránky určuje atribut parametry nezbytné pro nastavení příslušných hlaviček pro ukládání odpovědí do mezipaměti. Jediný parametr atributu [ResponseCache]
, který striktně vyžaduje middleware , VaryByQueryKeyskterý neodpovídá skutečné hlavičce HTTP. Další informace najdete v tématu Ukládání odpovědí do mezipaměti v ASP.NET Core.
Pokud atribut nepoužíváte [ResponseCache]
, ukládání odpovědí do mezipaměti se může lišit pomocí VaryByQueryKeys
. ResponseCachingFeature Použijte přímo z httpContext.Features:
var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();
if (responseCachingFeature != null)
{
responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}
Použití jedné hodnoty, která *
se rovná hodnotě, VaryByQueryKeys
se liší mezi mezipamětí podle všech parametrů dotazu požadavku.
Hlavičky HTTP používané middlewarem ukládání odpovědí do mezipaměti
Následující tabulka obsahuje informace o hlavičkách HTTP, které ovlivňují ukládání odpovědí do mezipaměti.
Hlavička | Detaily |
---|---|
Authorization |
Odpověď není uložená v mezipaměti, pokud hlavička existuje. |
Cache-Control |
Middleware bere v úvahu pouze odpovědi na ukládání do mezipaměti označené direktivou public cache. Řízení ukládání do mezipaměti pomocí následujících parametrů:
max-stale žádný limit , middleware nebude provádět žádnou akci.– proxy-revalidate má stejný účinek jako must-revalidate .Další informace naleznete v dokumentu RFC 9111: Direktivy požadavků. |
Pragma |
Hlavička Pragma: no-cache v požadavku vytvoří stejný účinek jako Cache-Control: no-cache . Tato hlavička je přepsána příslušnými direktivy v Cache-Control hlavičce, pokud je k dispozici. Zvažte zpětnou kompatibilitu s protokolem HTTP/1.0. |
Set-Cookie |
Odpověď není uložená v mezipaměti, pokud hlavička existuje. Jakýkoli middleware v kanálu zpracování požadavků, který nastaví jeden nebo více souborů cookie, zabraňuje middlewaru ukládání odpovědí do mezipaměti v ukládání odpovědi do mezipaměti (například cookieposkytovatel TempData založený na -based TempData). |
Vary |
Hlavička Vary se používá k různým odpovědím uloženým v mezipaměti podle jiné hlavičky. Například odpovědi mezipaměti kódováním zahrnutím hlavičky Vary: Accept-Encoding do mezipaměti, která ukládá odpovědi na požadavky s hlavičkami Accept-Encoding: gzip a Accept-Encoding: text/plain samostatně. Odpověď s hodnotou * hlavičky se nikdy neuloží. |
Expires |
Odpověď považována za zastaralou touto hlavičkou není uložená nebo načtená, pokud ji nepřepíše jiná Cache-Control hlavička. |
If-None-Match |
Úplná odpověď se obsluhuje z mezipaměti, pokud hodnota * není a ETag odpověď neodpovídá žádné zadané hodnotě. Jinak se obsluhuje odpověď 304 (Neupraveno). |
If-Modified-Since |
Pokud hlavička If-None-Match není k dispozici, úplná odpověď se obsluhuje z mezipaměti, pokud je datum odpovědi uložené v mezipaměti novější než zadaná hodnota. Jinak se obsluhuje odpověď 304 – Neupravená. |
Date |
Při poskytování z mezipaměti je hlavička nastavena middlewarem, Date pokud nebyla k dispozici v původní odpovědi. |
Content-Length |
Při poskytování z mezipaměti je hlavička nastavena middlewarem, Content-Length pokud nebyla k dispozici v původní odpovědi. |
Age |
Hlavička Age odeslaná v původní odpovědi se ignoruje. Middleware vypočítá novou hodnotu při poskytování odpovědi uložené v mezipaměti. |
Ukládání do mezipaměti respektuje direktivy Cache-Control
Middleware respektuje pravidla RFC 9111: Ukládání do mezipaměti HTTP (oddíl 5.2. Řízení mezipaměti). Pravidla vyžadují, aby byla v mezipaměti dodržena platná Cache-Control
hlavička odeslaná klientem. V rámci specifikace může klient vyžadovat požadavky s no-cache
hodnotou hlavičky a vynutit, aby server vygeneroval novou odpověď pro každý požadavek. V současné době neexistuje žádná kontrola nad tímto chováním při ukládání do mezipaměti při použití middlewaru, protože middleware dodržuje oficiální specifikaci ukládání do mezipaměti.
Pokud chcete mít větší kontrolu nad chováním při ukládání do mezipaměti, prozkoumejte další funkce ukládání do mezipaměti ASP.NET Core. Viz následující témata:
- Ukládání do mezipaměti v paměti v ASP.NET Core
- Distribuované ukládání do mezipaměti v ASP.NET Core
- Pomocná rutina značek mezipaměti v ASP.NET Core MVC
- Pomocná rutina značek distribuované mezipaměti v ASP.NET Core
Řešení problému
Pokud chování při ukládání do mezipaměti neodpovídá očekávání, ověřte, že odpovědi jsou uložené v mezipaměti a že je možné je obsluhovat z mezipaměti. Zkontrolujte příchozí hlavičky požadavku a odchozí hlavičky odpovědi. Povolte protokolování , které vám pomůže s laděním.
Při testování a řešení potíží s chováním ukládání do mezipaměti může prohlížeč nastavit hlavičky požadavků, které ovlivňují ukládání do mezipaměti nežádoucími způsoby. Například prohlížeč může záhlaví nastavit Cache-Control
na no-cache
nebo max-age=0
při aktualizaci stránky. Následující nástroje můžou explicitně nastavit hlavičky požadavků a jsou upřednostňované pro testování ukládání do mezipaměti:
Podmínky ukládání do mezipaměti
- Požadavek musí mít za následek odpověď serveru se stavovým kódem 200 (OK).
- Metoda požadavku musí být GET nebo HEAD.
- Middleware
Startup.Configure
pro ukládání odpovědí do mezipaměti musí být umístěn před middlewarem, který vyžaduje ukládání do mezipaměti. Další informace najdete v tématu Middleware ASP.NET Core. - Záhlaví
Authorization
nesmí být přítomno. Cache-Control
parametry hlavičky musí být platné a odpověď musí být označenapublic
a nesmí být označenaprivate
.- Záhlaví
Pragma: no-cache
nesmí být přítomno, pokudCache-Control
záhlaví není k dispozici, protožeCache-Control
záhlaví přepíše hlavičkuPragma
, když je k dispozici. - Záhlaví
Set-Cookie
nesmí být přítomno. Vary
parametry hlavičky musí být platné a nerovnají se*
.- Hodnota
Content-Length
hlavičky (pokud je nastavená) se musí shodovat s velikostí textu odpovědi. - Nepoužívá IHttpSendFileFeature se.
- Odpověď nesmí být zastaralá, jak je uvedeno v
Expires
hlavičce a direktiváchmax-age
mezipamětis-maxage
. - Ukládání odpovědí do vyrovnávací paměti musí být úspěšné. Velikost odpovědi musí být menší než nakonfigurovaná nebo výchozí SizeLimithodnota . Velikost těla odpovědi musí být menší než nakonfigurovaná nebo výchozí MaximumBodySizehodnota .
- Odpověď musí být uložená v mezipaměti podle dokumentu RFC 9111: Ukládání do mezipaměti HTTP. Například direktiva
no-store
nesmí existovat v polích hlavičky požadavku nebo odpovědi. Podrobnosti najdete v dokumentu RFC 9111: Ukládání odpovědí do mezipaměti http (oddíl 3: Ukládání odpovědí do mezipaměti .
Poznámka:
Antiforgery systém pro generování zabezpečených tokenů, aby se zabránilo útokům CSRF (Cross-Site Request Forgery), nastaví Cache-Control
a Pragma
hlavičky tak no-cache
, aby odpovědi nejsou uložené v mezipaměti. Informace o tom, jak zakázat antiforgery tokeny pro elementy formuláře HTML, naleznete v tématu Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core.
Další materiály
- Spuštění aplikace v ASP.NET Core
- ASP.NET Core Middleware
- Ukládání do mezipaměti v paměti v ASP.NET Core
- Distribuované ukládání do mezipaměti v ASP.NET Core
- Detekce změn pomocí tokenů změn v ASP.NET Core
- Ukládání odpovědí do mezipaměti v ASP.NET Core
- Pomocná rutina značek mezipaměti v ASP.NET Core MVC
- Pomocná rutina značek distribuované mezipaměti v ASP.NET Core