ASP.NET Core válasz gyorsítótárazó köztes szoftver

Készítette: John Luo és Rick Anderson

Ez a cikk bemutatja, hogyan konfigurálhatja a Response Caching Middleware-t egy ASP.NET Core-alkalmazásban. A köztes szoftver meghatározza, hogy a válaszok mikor gyorsítótárazhatók, tárolja a válaszokat, és a gyorsítótárból érkező válaszokat szolgálja ki. A HTTP-gyorsítótárazás és az [ResponseCache] attribútum bevezetéséhez lásd: Válasz gyorsítótárazása.

A válasz gyorsítótárazási köztes szoftvere:

• Engedélyezi a kiszolgálói válaszok gyorsítótárazását a HTTP-gyorsítótár fejlécei alapján. Implementálja a szabványos HTTP-gyorsítótárazási szemantikát. A proxykhoz hasonlóan a HTTP-gyorsítótár fejlécein alapuló gyorsítótárak.
• Általában nem előnyös az olyan felhasználói felületi alkalmazások esetében, mint a Razor Pages, mivel a böngészők általában olyan kérésfejléceket állítanak be, amelyek megakadályozzák a gyorsítótárazást. A .NET 7-es vagy újabb verzióiban elérhető kimeneti gyorsítótárazás a felhasználói felületi alkalmazások előnyeit biztosítja. A kimeneti gyorsítótárazással a konfiguráció dönti el, hogy mit kell gyorsítótárazni a HTTP-fejléctől függetlenül.
• Lehet, hogy hasznos a nyilvános GET- vagy HEAD API-kérésekhez olyan ügyfelek esetében, ahol teljesülnek a gyorsítótárazási feltételek.

A válasz gyorsítótárazásának teszteléséhez használja a Fiddlereszközt, vagy egy másik eszközt, amely explicit módon be tudja állítani a kérésfejléceket. A fejlécek egyértelmű beállítása a gyorsítótárazás teszteléséhez ajánlott. További információk: Hibaelhárítás.

Konfiguráció

Ebben Program.csadja hozzá a Response Caching Middleware-szolgáltatásokat AddResponseCaching a szolgáltatásgyűjteményhez, és konfigurálja az alkalmazást a köztes szoftver bővítménymetódussal való UseResponseCaching használatára. UseResponseCaching hozzáadja a köztes szoftvert a kérelemfeldolgozási folyamathoz:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

Figyelmeztetés

UseCors UseResponseCaching használatakor előbb kell meghívni.

A mintaalkalmazás fejléceket ad hozzá a következő kérések gyorsítótárazásának szabályozásához:

• Gyorsítótár-vezérlés: Legfeljebb 10 másodpercig gyorsítótárazza a gyorsítótárazható válaszokat.
• Változó: A köztes szoftvert csak akkor konfigurálja gyorsítótárazott válasz kiszolgálására, ha a későbbi kérések Accept-Encoding fejléce megegyezik az eredeti kérésével.

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();

Az előző fejlécek nincsenek a válaszba írva, és felülírva lesznek, amikor egy vezérlő, művelet vagy Razor oldal:

• [ResponseCache] attribútummal rendelkezik. Ez akkor is érvényes, ha egy tulajdonság nincs beállítva. Ha például kihagyja a VaryByHeader tulajdonságot, akkor a megfelelő fejléc el lesz távolítva a válaszból.

A Response Caching Middleware csak olyan kiszolgálói válaszokat gyorsítótáraz, amelyek 200 (OK) állapotkódot eredményeznek. A köztes szoftver figyelmen kívül hagyja a többi választ, beleértve a hibaoldalakat is.

Figyelmeztetés

A hitelesített ügyfelek számára tartalmat tartalmazó válaszokat nem gyorsítótárazhatóként kell megjelölni, hogy a köztes szoftver ne tárolja és szolgálja ki ezeket a válaszokat. A gyorsítótárazási feltételekkel kapcsolatos részletekért tekintse meg, hogy a köztes szoftver hogyan határozza meg, hogy a válasz gyorsítótárazható-e.

Az előző kód általában nem ad vissza gyorsítótárazott értéket a böngészőnek. Használja a Fiddlert vagy egy másik eszközt, amely explicit módon be tudja állítani a kérésfejléceket, és a gyorsítótárazás teszteléséhez előnyben részesíti. További információ: Hibaelhárítás ebben a cikkben.

Beállítások

A válasz gyorsítótárazási beállításai az alábbi táblázatban láthatók.

Lehetőség	Leírás
MaximumBodySize	A válasz törzsének legnagyobb gyorsítótárazható mérete bájtban. Az alapértelmezett érték 64 * 1024 * 1024 (64 MB).
SizeLimit	A válaszgyorsítótár köztes szoftverének méretkorlátja bájtban. Az alapértelmezett érték 100 * 1024 * 1024 (100 MB).
UseCaseSensitivePaths	Meghatározza, hogy a válaszok gyorsítótárazva vannak-e a kis- és nagybetűket megkülönböztető útvonalakon. Az alapértelmezett érték a false.

Az alábbi példa a köztes szoftver konfigurálását a következőre konfigurálja:

• Gyorsítótárazza azokat a válaszokat, amelyek törzsmérete kisebb vagy egyenlő 1,024 bájttal.
• A válaszokat az elérési útvonalak kis- és nagybetű érzékenységének figyelembevételével tárolja. Például, a /page1 és a /Page1 külön vannak tárolva.

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

MVC, webes API-vezérlők vagy Razor Pages-lapmodellek használatakor az [ResponseCache] attribútum megadja a válasz gyorsítótárazáshoz szükséges fejlécek beállításához szükséges paramétereket. A [ResponseCache] attribútum egyetlen paramétere, amelyet a köztes szoftver szigorúan megkövetel, az VaryByQueryKeys, amely nem felel meg tényleges HTTP-fejlécnek. További információért lásd: Válasz gyorsítótárazása az ASP.NET Core-ban.

Amikor nem használja a [ResponseCache] attribútumot, a válasz gyorsítótárazása módosítható a VaryByQueryKeys. Használja közvetlenül a ResponseCachingFeature elemet az HttpContext.Features közül:

var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();

if (responseCachingFeature != null)
{
    responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}

A * értékkel egyenlő egyetlen érték használata a VaryByQueryKeys-ben az összes lekérdezési paraméter szerint változtatja a gyorsítótárat.

A Response Caching Middleware által használt HTTP-fejlécek

Az alábbi táblázat a válasz gyorsítótárazását befolyásoló HTTP-fejlécekről nyújt információt.

Fejléc	Részletek
Authorization	Ha a fejléc létezik, a rendszer nem gyorsítótárazza a választ.
Cache-Control	A köztes szoftver csak a public gyorsítótár-irányelvvel megjelölt gyorsítótárazási válaszokat veszi figyelembe. A gyorsítótárazás szabályozása a következő paraméterekkel: maximális életkor maximálisan elavult† minimális frissesség kötelező újraérvényesítés gyorsítótár nélküli nincs áruház csak akkor, ha gyorsítótárazott privát nyilvános s-maxage proxy-revalidate‡ †Ha nincs megadva max-stalekorlát, a köztes szoftver nem hajt végre műveletet. proxy-revalidate‡ hatása megegyezik must-revalidatea . További információ: RFC 9111: Kérés irányelvek.
Pragma	A Pragma: no-cache kérelem fejléce ugyanazt a hatást eredményezi, mint a Cache-Control: no-cache. A fejléc vonatkozó Cache-Control irányelvei felülírják ezt a fejlécet, ha jelen vannak. A HTTP/1.0-val való visszamenőleges kompatibilitást tekintjük.
Set-Cookie	Ha a fejléc létezik, a rendszer nem gyorsítótárazza a választ. A kérésfeldolgozási folyamatban bármely köztes szoftver, amely egy vagy több cookie-t állít be, megakadályozza, hogy a Válasz gyorsítótárazása köztes szoftver tárolja a választ (például a cookie-alapú TempData szolgáltató).
Vary	A Vary fejléc a gyorsítótárazott válasz egy másik fejléc szerint történő változására szolgál. Például, a válaszok kódolással történő gyorsítótárazása érdekében használja a Vary: Accept-Encoding fejlécet, amely külön-külön gyorsítótárazza a Accept-Encoding: gzip és Accept-Encoding: text/plain fejléccel rendelkező kérések válaszait. A fejlécértékkel * rendelkező válaszok soha nem lesznek tárolva.
Expires	A fejléc által elavultnak ítélt választ nem tárolják vagy kérik le, kivéve, ha más Cache-Control fejlécek felülbírálják.
If-None-Match	A rendszer a teljes választ a gyorsítótárból kézbesíti, ha az érték nem * , és a ETag válasz nem egyezik a megadott értékekkel. Ellenkező esetben a rendszer 304(Nem módosított) választ kézbesít.
If-Modified-Since	Ha a If-None-Match fejléc nem található, a rendszer teljes választ ad a gyorsítótárból, ha a gyorsítótárazott válasz dátuma újabb, mint a megadott érték. Ellenkező esetben a rendszer a 304 – Nem módosított választ kézbesíti.
Date	Amikor a gyorsítótárból küldünk, a Date fejlécet a közbenső réteg állítja be, ha az eredeti válaszban nem volt megadva.
Content-Length	Amikor a gyorsítótárból küldünk, a Content-Length fejlécet a közbenső réteg állítja be, ha az eredeti válaszban nem volt megadva.
Age	Az Age eredeti válaszban küldött fejléc figyelmen kívül lesz hagyva. A köztes szoftver egy új értéket számít ki a gyorsítótárazott válasz kiszolgálásakor.

A gyorsítótárazás tiszteletben tartja a Cache-Control kérelem irányelveit.

A köztes szoftver tiszteletben tartja az RFC 9111: HTTP-gyorsítótárazás (5.2. Cache-Control. szakasz) szabályait. A szabályok megkövetelik, hogy a gyorsítótár betartsa az ügyfél által küldött érvényes Cache-Control fejlécet. A specifikáció szerint az ügyfél fejlécértékkel no-cache rendelkező kéréseket kezdeményezhet, és kényszerítheti a kiszolgálót, hogy minden kérésre új választ hozzon létre. Jelenleg nincs fejlesztői ellenőrzés a gyorsítótárazási viselkedés felett a köztes szoftver használatakor, mivel a köztes szoftver megfelel a hivatalos gyorsítótárazási specifikációnak.

A gyorsítótárazási viselkedés további szabályozásához tekintse meg a ASP.NET Core egyéb gyorsítótárazási funkcióit. Tekintse meg a következő témaköröket:

• Memóriabeli gyorsítótárazás ASP.NET Core
• Elosztott gyorsítótárazás az ASP.NET Core-ban
• Cache Tag Helper az ASP.NET Core MVC
• Elosztott gyorsítótár címke segédprogram az ASP.NET Core-ban

Hibaelhárítás

A Response Caching Middleware korlátozott kapacitású megoldásokat használ IMemoryCache. A kapacitás túllépésekor a memóriagyorsítótár tömörítve lesz.

Ha a gyorsítótárazási viselkedés nem a várt módon történik, győződjön meg arról, hogy a válaszok gyorsítótárazhatók, és képesek a gyorsítótárból való kézbesítésre. Vizsgálja meg a kérés bejövő fejléceit és a válasz kimenő fejléceit. Engedélyezze a naplózást , hogy segítsen a hibakeresésben.

A gyorsítótárazási viselkedés tesztelése és hibaelhárítása során a böngésző általában olyan kérésfejléceket állít be, amelyek megakadályozzák a gyorsítótárazást. Előfordulhat például, hogy egy böngésző beállítja a Cache-Control fejlécet no-cache vagy max-age=0 egy oldal frissítésekor. Fiddler és más eszközök kifejezetten beállíthatják a kérésfejléceket, és előnyösek a gyorsítótárazás tesztelésére.

A gyorsítótárazáshoz szükséges feltételek

• A kérésnek 200 (OK) állapotkóddal rendelkező kiszolgálói választ kell eredményeznie.
• A kérelem metódusának GET vagy HEAD kell lennie.
• A válasz-gyorsítótárazás köztes szoftvert a gyorsítótárazást igénylő köztes szoftver elé kell helyezni. További információ: ASP.NET Core Middleware.
• A Authorization fejléc nem lehet jelen.
• Cache-Control a fejlécparamétereknek érvényesnek kell lenniük, a választ pedig meg kell jelölni public , és nem kell megjelölni private.
• Az Pragma: no-cache fejléc nem lehet jelen, ha az Cache-Control fejléc nincs jelen, mivel a Cache-Control fejléc felülírja a Pragma fejlécet, amikor jelen van.
• A Set-Cookie fejléc nem lehet jelen.
• Varya fejléc paramétereinek érvényesnek és nem egyenlőnek kell lenniük.*
• A Content-Length fejléc értékének (ha be van állítva) meg kell egyeznie a válasz törzsének méretével.
• A IHttpSendFileFeature nincs használatban.
• A válasz nem lehet elavult a fejléc és a Expiresmax-ages-maxage gyorsítótár irányelvei által meghatározottak szerint.
• A válaszpufferelésnek sikeresnek kell lennie. A válasz méretének kisebbnek kell lennie, mint a konfigurált vagy az alapértelmezett SizeLimit. A válasz törzsméretének kisebbnek kell lennie, mint a konfigurált vagy az alapértelmezett MaximumBodySize.
• A válasznak gyorsítótárazhatónak kell lennie az RFC 9111: HTTP-gyorsítótárazás szerint. Például az no-store irányelv nem létezhet a kérelem- vagy válaszfejlécmezőkben. Részletekért lásd az RFC 9111: HTTP-gyorsítótárazást (3. szakasz: Válaszok tárolása a gyorsítótárakban ).

Megjegyzés:

Az Antiforgery rendszer, amely biztonságos jogkivonatokat hoz létre az oldalak közötti hamisítás (CSRF) elleni támadások megakadályozása érdekében, beállítja a Cache-Control és Pragma fejléceket no-cache-re, hogy a válaszok ne legyenek gyorsítótárazva. További információ a HTML-űrlapelemek antiforgery tokenjeinek letiltásáról: A helyek közötti kérelemhamisítás (XSRF/CSRF) támadásainak megakadályozása a ASP.NET Core-ban.

További erőforrások

• Mintakód megtekintése vagy letöltése (hogyan töltsd le)
• GitHub-forrás a következőhöz: IResponseCachingPolicyProvider
• GitHub-forrás a következőhöz: IResponseCachingPolicyProvider
• alkalmazás indítása a ASP.NET Core
• ASP.NET Core köztes szoftver
• Memóriabeli gyorsítótárazás ASP.NET Core
• Elosztott gyorsítótárazás az ASP.NET Core-ban
• Változások észlelése változási tokenekkel az ASP.NET Core
• Válasz gyorsítótárazása az ASP.NET Core-ban
• Cache Tag Helper az ASP.NET Core MVC
• Elosztott gyorsítótár címke segédprogram az ASP.NET Core-ban