Middleware di memorizzazione nella cache delle risposte in ASP.NET Core
Di John Luo e Rick Anderson
Questo articolo illustra come configurare il middleware di memorizzazione nella cache delle risposte in un'app core ASP.NET. Il middleware determina quando le risposte sono memorizzabili nella cache, archiviano le risposte e servono risposte dalla cache. Per un'introduzione alla memorizzazione nella cache HTTP e all'attributo [ResponseCache]
, vedere Memorizzazione nella cache delle risposte.
Middleware di memorizzazione nella cache della risposta:
- Abilita la memorizzazione nella cache delle risposte del server in base alle intestazioni della cache HTTP. Implementa la semantica di memorizzazione nella cache HTTP standard. Memorizza nella cache le intestazioni della cache HTTP come i proxy.
- In genere non è utile per le app dell'interfaccia utente, ad Razor esempio Pagine, perché i browser impostano in genere intestazioni di richiesta che impediscono la memorizzazione nella cache. La memorizzazione nella cache di output, disponibile in ASP.NET Core 7.0 e versioni successive, offre vantaggi alle app dell'interfaccia utente. Con la memorizzazione nella cache dell'output, la configurazione decide cosa deve essere memorizzato nella cache indipendentemente da intestazioni HTTP.
- Può essere utile per le richieste API GET o HEAD pubbliche dai client in cui vengono soddisfatte le condizioni per la memorizzazione nella cache .
Per testare la memorizzazione nella cache delle risposte, usare Fiddler o un altro strumento in grado di impostare in modo esplicito le intestazioni della richiesta. L'impostazione esplicita delle intestazioni è preferibile per il test della memorizzazione nella cache. Per ulteriori informazioni, vedere Risoluzione dei problemi.
Impostazione
In Program.cs
aggiungere i servizi middleware di memorizzazione nella cache delle risposte alla raccolta di servizi AddResponseCaching e configurare l'app per l'uso del middleware con il UseResponseCaching metodo di estensione. UseResponseCaching
aggiunge il middleware alla pipeline di elaborazione delle richieste:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCaching();
var app = builder.Build();
app.UseHttpsRedirection();
// UseCors must be called before UseResponseCaching
//app.UseCors();
app.UseResponseCaching();
Avviso
UseCors deve essere chiamato prima di UseResponseCaching quando si usa il middleware CORS.
L'app di esempio aggiunge intestazioni per controllare la memorizzazione nella cache nelle richieste successive:
- Cache-Control: memorizza nella cache le risposte memorizzabili nella cache per un massimo di 10 secondi.
- Variare: configura il middleware per gestire una risposta memorizzata nella cache solo se l'intestazione Accept-Encoding delle richieste successive corrisponde a quella della richiesta originale.
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();
Le intestazioni precedenti non vengono scritte nella risposta e vengono sottoposte a override quando un controller, un'azione o Razor una pagina:
- Ha un attributo [ResponseCache]. Questo vale anche se una proprietà non è impostata. Se ad esempio si omette la proprietà VaryByHeader , l'intestazione corrispondente verrà rimossa dalla risposta.
Il middleware di memorizzazione nella cache della risposta memorizza nella cache solo le risposte del server che generano un codice di stato 200 (OK). Tutte le altre risposte, incluse le pagine di errore, vengono ignorate dal middleware.
Avviso
Le risposte contenenti contenuto per i client autenticati devono essere contrassegnate come non memorizzabili nella cache per impedire al middleware di archiviare e gestire tali risposte. Per informazioni dettagliate su come il middleware determina se una risposta è memorizzabile nella cache, vedere Condizioni per la memorizzazione nella cache .
Il codice precedente in genere non restituisce un valore memorizzato nella cache in un browser. Usare Fiddler o un altro strumento in grado di impostare in modo esplicito le intestazioni delle richieste ed è preferibile per il test della memorizzazione nella cache. Per altre informazioni, vedere Risoluzione dei problemi in questo articolo.
Opzioni
Le opzioni di memorizzazione nella cache delle risposte sono illustrate nella tabella seguente.
Opzione | Descrizione |
---|---|
MaximumBodySize | Dimensione memorizzabile nella cache massima per il corpo della risposta in byte. Il valore predefinito è 64 * 1024 * 1024 (64 MB). |
SizeLimit | Limite di dimensioni per il middleware della cache delle risposte in byte. Il valore predefinito è 100 * 1024 * 1024 (100 MB). |
UseCaseSensitivePaths | Determina se le risposte vengono memorizzate nella cache nei percorsi con distinzione tra maiuscole e minuscole. Il valore predefinito è false . |
L'esempio seguente configura il middleware per:
- Memorizzare nella cache le risposte con dimensioni del corpo inferiori o uguali a 1.024 byte.
- Archiviare le risposte in base ai percorsi con distinzione tra maiuscole e minuscole. Ad esempio,
/page1
e/Page1
vengono archiviati separatamente.
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
Quando si usano modelli di pagina MVC, controller API Web o Razor Pagine, l'attributo [ResponseCache]
specifica i parametri necessari per impostare le intestazioni appropriate per la memorizzazione nella cache delle risposte. L'unico parametro dell'attributo [ResponseCache]
che richiede rigorosamente il middleware è VaryByQueryKeys, che non corrisponde a un'intestazione HTTP effettiva. Per altre informazioni, vedere Memorizzazione nella cache delle risposte in ASP.NET Core.
Quando non si usa l'attributo , la [ResponseCache]
memorizzazione nella cache delle risposte può essere variata con VaryByQueryKeys
. Usare direttamente ResponseCachingFeature da HttpContext.Features:
var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();
if (responseCachingFeature != null)
{
responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}
L'uso di un singolo valore uguale a in VaryByQueryKeys
varia la cache in base a *
tutti i parametri di query della richiesta.
Intestazioni HTTP usate dal middleware di memorizzazione nella cache delle risposte
Nella tabella seguente vengono fornite informazioni sulle intestazioni HTTP che influiscono sulla memorizzazione nella cache delle risposte.
Intestazione | Dettagli |
---|---|
Authorization |
La risposta non viene memorizzata nella cache se l'intestazione esiste. |
Cache-Control |
Il middleware considera solo le risposte di memorizzazione nella cache contrassegnate con la direttiva cache public . Controllare la memorizzazione nella cache con i parametri seguenti:
max-stale , il middleware non esegue alcuna azione.* proxy-revalidate ha lo stesso effetto di must-revalidate .Per altre informazioni, vedere RFC 9111: Direttive di richiesta. |
Pragma |
Un'intestazione Pragma: no-cache nella richiesta produce lo stesso effetto di Cache-Control: no-cache . Questa intestazione viene sostituita dalle direttive pertinenti nell'intestazione Cache-Control , se presente. Considerato per compatibilità con le versioni precedenti con HTTP/1.0. |
Set-Cookie |
La risposta non viene memorizzata nella cache se l'intestazione esiste. Qualsiasi middleware nella pipeline di elaborazione delle richieste che imposta uno o più cookie impedisce al middleware di Memorizzazione nella cache della risposta di memorizzare nella cache la risposta, ad esempio il cookieprovider TempData basato su . |
Vary |
L'intestazione Vary viene usata per variare la risposta memorizzata nella cache in base a un'altra intestazione. Ad esempio, memorizzare nella cache le risposte in base alla codifica includendo l'intestazione Vary: Accept-Encoding , che memorizza nella cache le risposte per le richieste con intestazioni Accept-Encoding: gzip e Accept-Encoding: text/plain separatamente. Una risposta con un valore di intestazione di * non viene mai archiviata. |
Expires |
Una risposta considerata non aggiornata da questa intestazione non viene archiviata o recuperata a meno che non venga sottoposta a override da altre Cache-Control intestazioni. |
If-None-Match |
La risposta completa viene servita dalla cache se il valore non * è e l'oggetto ETag della risposta non corrisponde ad alcuno dei valori specificati. In caso contrario, viene fornita una risposta 304 (non modificata). |
If-Modified-Since |
Se l'intestazione If-None-Match non è presente, viene fornita una risposta completa dalla cache se la data di risposta memorizzata nella cache è più recente del valore specificato. In caso contrario, viene servita una risposta 304 - Non modificata . |
Date |
Quando si gestisce dalla cache, l'intestazione Date viene impostata dal middleware se non è stata specificata nella risposta originale. |
Content-Length |
Quando si gestisce dalla cache, l'intestazione Content-Length viene impostata dal middleware se non è stata specificata nella risposta originale. |
Age |
L'intestazione Age inviata nella risposta originale viene ignorata. Il middleware calcola un nuovo valore quando si gestisce una risposta memorizzata nella cache. |
La memorizzazione nella cache rispetta le direttive cache-control della richiesta
Il middleware rispetta le regole di RFC 9111: memorizzazione nella cache HTTP (sezione 5.2). Cache-Control). Le regole richiedono una cache per rispettare un'intestazione valida Cache-Control
inviata dal client. In base alla specifica, un client può effettuare richieste con un no-cache
valore di intestazione e forzare il server a generare una nuova risposta per ogni richiesta. Attualmente, non esiste alcun controllo dello sviluppatore su questo comportamento di memorizzazione nella cache quando si usa il middleware perché il middleware è conforme alla specifica ufficiale di memorizzazione nella cache.
Per un maggiore controllo sul comportamento di memorizzazione nella cache, esplorare altre funzionalità di memorizzazione nella cache di ASP.NET Core. Vedi gli argomenti seguenti:
- Cache in memoria in ASP.NET Core
- Memorizzazione nella cache distribuita in ASP.NET Core
- Cache Tag Helper in ASP.NET Core MVC
- Helper tag cache distribuita in ASP.NET Core
Risoluzione dei problemi
Il middleware di memorizzazione nella cache delle risposte usa IMemoryCache, che ha una capacità limitata. Quando viene superata la capacità, la cache di memoria viene compattata.
Se il comportamento di memorizzazione nella cache non è quello previsto, verificare che le risposte siano memorizzabili nella cache e in grado di essere gestite dalla cache. Esaminare le intestazioni in ingresso della richiesta e le intestazioni in uscita della risposta. Abilitare la registrazione per facilitare il debug.
Durante il test e la risoluzione dei problemi relativi al comportamento di memorizzazione nella cache, un browser imposta in genere le intestazioni di richiesta che impediscono la memorizzazione nella cache. Ad esempio, un browser può impostare l'intestazione Cache-Control
su no-cache
o max-age=0
quando si aggiorna una pagina. Fiddler e altri strumenti possono impostare in modo esplicito le intestazioni delle richieste e sono preferiti per il test della memorizzazione nella cache.
Condizioni per la memorizzazione nella cache
- La richiesta deve generare una risposta del server con un codice di stato 200 (OK).
- Il metodo della richiesta deve essere GET o HEAD.
- Il middleware di memorizzazione nella cache della risposta deve essere inserito prima del middleware che richiede la memorizzazione nella cache. Per altre informazioni, vedere Middleware ASP.NET Core.
- L'intestazione
Authorization
non deve essere presente. Cache-Control
I parametri di intestazione devono essere validi e la risposta deve essere contrassegnatapublic
e non contrassegnata.private
- L'intestazione
Pragma: no-cache
non deve essere presente se l'intestazioneCache-Control
non è presente, perché l'intestazione esegue l'overrideCache-Control
dell'intestazionePragma
quando presente. - L'intestazione
Set-Cookie
non deve essere presente. Vary
I parametri di intestazione devono essere validi e non uguali a*
.- Il
Content-Length
valore dell'intestazione (se impostato) deve corrispondere alle dimensioni del corpo della risposta. - L'oggetto IHttpSendFileFeature non viene usato.
- La risposta non deve essere obsoleta come specificato dall'intestazione
Expires
e dallemax-age
direttive della cache es-maxage
. - Il buffer delle risposte deve avere esito positivo. Le dimensioni della risposta devono essere inferiori a quelle configurate o predefinite SizeLimit. Le dimensioni del corpo della risposta devono essere inferiori a quelle configurate o predefinite MaximumBodySize.
- La risposta deve essere memorizzata nella cache in base a RFC 9111: memorizzazione nella cache HTTP. Ad esempio, la
no-store
direttiva non deve esistere nei campi di intestazione della richiesta o della risposta. Per informazioni dettagliate, vedere RFC 9111: Memorizzazione nella cache HTTP (sezione 3: Archiviazione di risposte nelle cache ).
Nota
Il sistema Antiforgery per la generazione di token sicuri per evitare attacchi CSRF (Cross-Site Request Forgery) imposta le Cache-Control
intestazioni e Pragma
su no-cache
in modo che le risposte non vengano memorizzate nella cache. Per informazioni su come disabilitare i token antiforgery per gli elementi del modulo HTML, vedere Impedire attacchi xsrf/CSRF (Cross-Site Request Forgery) in ASP.NET Core.
Risorse aggiuntive
- Visualizzare o scaricare il codice di esempio (procedura per il download)
- Origine GitHub per
IResponseCachingPolicyProvider
- Origine GitHub per
IResponseCachingPolicyProvider
- Avvio dell'app in ASP.NET Core
- Middleware di ASP.NET Core
- Cache in memoria in ASP.NET Core
- Memorizzazione nella cache distribuita in ASP.NET Core
- Rilevare le modifiche con i token di modifica in ASP.NET Core
- Memorizzazione nella cache delle risposte in ASP.NET Core
- Cache Tag Helper in ASP.NET Core MVC
- Helper tag cache distribuita in ASP.NET Core
Questo articolo illustra come configurare il middleware di memorizzazione nella cache delle risposte in un'app core ASP.NET. Il middleware determina quando le risposte sono memorizzabili nella cache, archiviano le risposte e servono risposte dalla cache. Per un'introduzione alla memorizzazione nella cache HTTP e all'attributo [ResponseCache]
, vedere Memorizzazione nella cache delle risposte.
Visualizzare o scaricare il codice di esempio (procedura per il download)
Impostazione
Il middleware di memorizzazione nella cache delle risposte è disponibile in modo implicito per ASP.NET app Core tramite il framework condiviso.
In Startup.ConfigureServices
aggiungere il middleware di memorizzazione nella cache delle risposte alla raccolta di servizi:
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddRazorPages();
}
Configurare l'app per l'uso del middleware con il UseResponseCaching metodo di estensione, che aggiunge il middleware alla pipeline di elaborazione delle richieste in 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();
});
}
Avviso
UseCors deve essere chiamato prima di UseResponseCaching quando si usa il middleware CORS.
L'app di esempio aggiunge intestazioni per controllare la memorizzazione nella cache nelle richieste successive:
- Cache-Control: memorizza nella cache le risposte memorizzabili nella cache per un massimo di 10 secondi.
- Variare: configura il middleware per gestire una risposta memorizzata nella cache solo se l'intestazione Accept-Encoding delle richieste successive corrisponde a quella della richiesta originale.
// 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();
});
Le intestazioni precedenti non vengono scritte nella risposta e vengono sottoposte a override quando un controller, un'azione o Razor una pagina:
- Ha un attributo [ResponseCache]. Questo vale anche se una proprietà non è impostata. Se ad esempio si omette la proprietà VaryByHeader , l'intestazione corrispondente verrà rimossa dalla risposta.
Il middleware di memorizzazione nella cache della risposta memorizza nella cache solo le risposte del server che generano un codice di stato 200 (OK). Tutte le altre risposte, incluse le pagine di errore, vengono ignorate dal middleware.
Avviso
Le risposte contenenti contenuto per i client autenticati devono essere contrassegnate come non memorizzabili nella cache per impedire al middleware di archiviare e gestire tali risposte. Per informazioni dettagliate su come il middleware determina se una risposta è memorizzabile nella cache, vedere Condizioni per la memorizzazione nella cache .
Opzioni
Le opzioni di memorizzazione nella cache delle risposte sono illustrate nella tabella seguente.
Opzione | Descrizione |
---|---|
MaximumBodySize | Dimensione memorizzabile nella cache massima per il corpo della risposta in byte. Il valore predefinito è 64 * 1024 * 1024 (64 MB). |
SizeLimit | Limite di dimensioni per il middleware della cache delle risposte in byte. Il valore predefinito è 100 * 1024 * 1024 (100 MB). |
UseCaseSensitivePaths | Determina se le risposte vengono memorizzate nella cache nei percorsi con distinzione tra maiuscole e minuscole. Il valore predefinito è false . |
L'esempio seguente configura il middleware per:
- Memorizzare nella cache le risposte con dimensioni del corpo inferiori o uguali a 1.024 byte.
- Archiviare le risposte in base ai percorsi con distinzione tra maiuscole e minuscole. Ad esempio,
/page1
e/Page1
vengono archiviati separatamente.
services.AddResponseCaching(options =>
{
options.MaximumBodySize = 1024;
options.UseCaseSensitivePaths = true;
});
VaryByQueryKeys
Quando si usano controller API MVC/Web o Razor modelli di pagina Pagine, l'attributo [ResponseCache]
specifica i parametri necessari per impostare le intestazioni appropriate per la memorizzazione nella cache delle risposte. L'unico parametro dell'attributo [ResponseCache]
che richiede rigorosamente il middleware è VaryByQueryKeys, che non corrisponde a un'intestazione HTTP effettiva. Per altre informazioni, vedere Memorizzazione nella cache delle risposte in ASP.NET Core.
Quando non si usa l'attributo , la [ResponseCache]
memorizzazione nella cache delle risposte può essere variata con VaryByQueryKeys
. Usare direttamente ResponseCachingFeature da HttpContext.Features:
var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();
if (responseCachingFeature != null)
{
responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}
L'uso di un singolo valore uguale a in VaryByQueryKeys
varia la cache in base a *
tutti i parametri di query della richiesta.
Intestazioni HTTP usate dal middleware di memorizzazione nella cache delle risposte
Nella tabella seguente vengono fornite informazioni sulle intestazioni HTTP che influiscono sulla memorizzazione nella cache delle risposte.
Intestazione | Dettagli |
---|---|
Authorization |
La risposta non viene memorizzata nella cache se l'intestazione esiste. |
Cache-Control |
Il middleware considera solo le risposte di memorizzazione nella cache contrassegnate con la direttiva cache public . Controllare la memorizzazione nella cache con i parametri seguenti:
max-stale , il middleware non esegue alcuna azione.* proxy-revalidate ha lo stesso effetto di must-revalidate .Per altre informazioni, vedere RFC 9111: Direttive di richiesta. |
Pragma |
Un'intestazione Pragma: no-cache nella richiesta produce lo stesso effetto di Cache-Control: no-cache . Questa intestazione viene sostituita dalle direttive pertinenti nell'intestazione Cache-Control , se presente. Considerato per compatibilità con le versioni precedenti con HTTP/1.0. |
Set-Cookie |
La risposta non viene memorizzata nella cache se l'intestazione esiste. Qualsiasi middleware nella pipeline di elaborazione delle richieste che imposta uno o più cookie impedisce al middleware di Memorizzazione nella cache della risposta di memorizzare nella cache la risposta, ad esempio il cookieprovider TempData basato su . |
Vary |
L'intestazione Vary viene usata per variare la risposta memorizzata nella cache in base a un'altra intestazione. Ad esempio, memorizzare nella cache le risposte in base alla codifica includendo l'intestazione Vary: Accept-Encoding , che memorizza nella cache le risposte per le richieste con intestazioni Accept-Encoding: gzip e Accept-Encoding: text/plain separatamente. Una risposta con un valore di intestazione di * non viene mai archiviata. |
Expires |
Una risposta considerata non aggiornata da questa intestazione non viene archiviata o recuperata a meno che non venga sottoposta a override da altre Cache-Control intestazioni. |
If-None-Match |
La risposta completa viene servita dalla cache se il valore non * è e l'oggetto ETag della risposta non corrisponde ad alcuno dei valori specificati. In caso contrario, viene fornita una risposta 304 (non modificata). |
If-Modified-Since |
Se l'intestazione If-None-Match non è presente, viene fornita una risposta completa dalla cache se la data di risposta memorizzata nella cache è più recente del valore specificato. In caso contrario, viene servita una risposta 304 - Non modificata . |
Date |
Quando si gestisce dalla cache, l'intestazione Date viene impostata dal middleware se non è stata specificata nella risposta originale. |
Content-Length |
Quando si gestisce dalla cache, l'intestazione Content-Length viene impostata dal middleware se non è stata specificata nella risposta originale. |
Age |
L'intestazione Age inviata nella risposta originale viene ignorata. Il middleware calcola un nuovo valore quando si gestisce una risposta memorizzata nella cache. |
La memorizzazione nella cache rispetta le direttive cache-control della richiesta
Il middleware rispetta le regole di RFC 9111: memorizzazione nella cache HTTP (sezione 5.2). Cache-Control). Le regole richiedono una cache per rispettare un'intestazione valida Cache-Control
inviata dal client. In base alla specifica, un client può effettuare richieste con un no-cache
valore di intestazione e forzare il server a generare una nuova risposta per ogni richiesta. Attualmente, non esiste alcun controllo dello sviluppatore su questo comportamento di memorizzazione nella cache quando si usa il middleware perché il middleware è conforme alla specifica ufficiale di memorizzazione nella cache.
Per un maggiore controllo sul comportamento di memorizzazione nella cache, esplorare altre funzionalità di memorizzazione nella cache di ASP.NET Core. Vedi gli argomenti seguenti:
- Cache in memoria in ASP.NET Core
- Memorizzazione nella cache distribuita in ASP.NET Core
- Cache Tag Helper in ASP.NET Core MVC
- Helper tag cache distribuita in ASP.NET Core
Risoluzione dei problemi
Se il comportamento di memorizzazione nella cache non è quello previsto, verificare che le risposte siano memorizzabili nella cache e in grado di essere gestite dalla cache. Esaminare le intestazioni in ingresso della richiesta e le intestazioni in uscita della risposta. Abilitare la registrazione per facilitare il debug.
Durante i test e la risoluzione dei problemi relativi al comportamento di memorizzazione nella cache, un browser può impostare intestazioni di richiesta che influiscono sulla memorizzazione nella cache in modi indesiderati. Ad esempio, un browser può impostare l'intestazione Cache-Control
su no-cache
o max-age=0
quando si aggiorna una pagina. Gli strumenti seguenti possono impostare in modo esplicito le intestazioni delle richieste e sono preferibili per il test della memorizzazione nella cache:
Condizioni per la memorizzazione nella cache
- La richiesta deve generare una risposta del server con un codice di stato 200 (OK).
- Il metodo della richiesta deve essere GET o HEAD.
- In
Startup.Configure
, il middleware di memorizzazione nella cache delle risposte deve essere inserito prima del middleware che richiede la memorizzazione nella cache. Per altre informazioni, vedere Middleware ASP.NET Core. - L'intestazione
Authorization
non deve essere presente. Cache-Control
I parametri di intestazione devono essere validi e la risposta deve essere contrassegnatapublic
e non contrassegnata.private
- L'intestazione
Pragma: no-cache
non deve essere presente se l'intestazioneCache-Control
non è presente, perché l'intestazione esegue l'overrideCache-Control
dell'intestazionePragma
quando presente. - L'intestazione
Set-Cookie
non deve essere presente. Vary
I parametri di intestazione devono essere validi e non uguali a*
.- Il
Content-Length
valore dell'intestazione (se impostato) deve corrispondere alle dimensioni del corpo della risposta. - L'oggetto IHttpSendFileFeature non viene usato.
- La risposta non deve essere obsoleta come specificato dall'intestazione
Expires
e dallemax-age
direttive della cache es-maxage
. - Il buffer delle risposte deve avere esito positivo. Le dimensioni della risposta devono essere inferiori a quelle configurate o predefinite SizeLimit. Le dimensioni del corpo della risposta devono essere inferiori a quelle configurate o predefinite MaximumBodySize.
- La risposta deve essere memorizzata nella cache in base a RFC 9111: memorizzazione nella cache HTTP. Ad esempio, la
no-store
direttiva non deve esistere nei campi di intestazione della richiesta o della risposta. Per informazioni dettagliate, vedere RFC 9111: Memorizzazione nella cache HTTP (sezione 3: Archiviazione di risposte nelle cache ).
Nota
Il sistema Antiforgery per la generazione di token sicuri per evitare attacchi CSRF (Cross-Site Request Forgery) imposta le Cache-Control
intestazioni e Pragma
su no-cache
in modo che le risposte non vengano memorizzate nella cache. Per informazioni su come disabilitare i token antiforgery per gli elementi del modulo HTML, vedere Impedire attacchi xsrf/CSRF (Cross-Site Request Forgery) in ASP.NET Core.
Risorse aggiuntive
- Avvio dell'app in ASP.NET Core
- Middleware di ASP.NET Core
- Cache in memoria in ASP.NET Core
- Memorizzazione nella cache distribuita in ASP.NET Core
- Rilevare le modifiche con i token di modifica in ASP.NET Core
- Memorizzazione nella cache delle risposte in ASP.NET Core
- Cache Tag Helper in ASP.NET Core MVC
- Helper tag cache distribuita in ASP.NET Core