Mise en cache des réponses dans ASP.NET Core

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

La mise en cache des réponses réduit le nombre de demandes qu’un client ou un proxy effectue à un serveur web. La mise en cache des réponses réduit également la quantité de travail que le serveur web effectue pour générer une réponse. La mise en cache des réponses est définie dans les en-têtes.

L’attribut ResponseCache définit les en-têtes de mise en cache des réponses. Les clients et les proxys intermédiaires doivent respecter les en-têtes pour la mise en cache des réponses sous RFC 9111 : Mise en cache HTTP.

Pour la mise en cache côté serveur qui suit la spécification de mise en cache HTTP 1.1, utilisez l’intergiciel de mise en cache de réponse. Le middleware peut utiliser les propriétés ResponseCacheAttribute pour influencer le comportement de mise en cache côté serveur.

L’intergiciel de mise en cache des réponses :

• Active la mise en cache des réponses du serveur en fonction des en-têtes de cache HTTP. Implémente la sémantique de mise en cache HTTP standard. Caches basés sur des en-têtes de cache HTTP comme les proxys.
• N’est généralement pas bénéfique pour les applications d’interface utilisateur telles que Razor Pages, car les navigateurs définissent habituellement des en-têtes de requête qui empêchent la mise en cache. La mise en cache de sortie, disponible dans ASP.NET Core 7.0 et versions ultérieures, bénéficie aux applications d’interface utilisateur. Avec la mise en cache de sortie, la configuration détermine ce qui doit être mis en cache indépendamment des en-têtes HTTP.
• Peut être utile pour les demandes d’API GET ou HEAD publiques provenant de clients pour lesquels les conditions de mise en cache sont remplies.

Pour tester la mise en cache des réponses, utilisez Fiddler ou un autre outil qui peut définir explicitement des en-têtes de requête. La définition explicite d’en-têtes est recommandée pour tester la mise en cache. Pour plus d’informations, consultez la page Dépannage.

Mise en cache des réponses basée sur HTTP

RFC 9111 : Mise en cache HTTP décrit le comportement des caches Internet. L’en-tête HTTP principal utilisé pour la mise en cache est Cache-Control, qui est utilisé pour spécifier des directives de cache. Les directives contrôlent le comportement de mise en cache à mesure que les demandes se rendent des clients aux serveurs et que les réponses se rendent des serveurs aux clients. Les requêtes et les réponses transitent par les serveurs proxy, et les serveurs proxy doivent également se conformer à la spécification de mise en cache HTTP 1.1.

Les directives Cache-Control communes sont affichées dans le tableau suivant.

Les autres en-têtes de cache qui jouent un rôle dans la mise en cache sont indiqués dans le tableau suivant.

La mise en cache basée sur HTTP respecte les directives de Cache-Control de requête

RFC 9111 : Mise en cache HTTP (section 5.2. Cache-Control) nécessite un cache pour honorer un en-tête valide Cache-Control envoyé par le client. Un client peut effectuer des requêtes avec une valeur d’en-tête no-cache et forcer le serveur à générer une nouvelle réponse pour chaque requête.

Toujours respecter les en-têtes de requête client Cache-Control est logique si vous envisagez l’objectif de la mise en cache HTTP. Selon la spécification officielle, la mise en cache est destinée à réduire la latence et la surcharge réseau des demandes satisfaisantes sur un réseau de clients, de proxys et de serveurs. Il ne s’agit pas nécessairement d’un moyen de contrôler la charge sur un serveur d’origine.

Il n’existe aucun contrôle de développeur sur ce comportement de mise en cache lors de l’utilisation du middleware de mise en cache de réponse, car le middleware respecte la spécification de mise en cache officielle. La prise en charge de la mise en cache de sortie pour mieux contrôler la charge du serveur a été ajoutée dans .NET 7. Pour plus d’informations, consultez Cache de sortie.

Attribut ResponseCache

Le ResponseCacheAttribute spécifie les paramètres nécessaires pour définir les en-têtes appropriés dans la mise en cache des réponses.

VaryByQueryKeys varie la réponse stockée en fonction des valeurs de la liste donnée de clés de requête. Lorsqu’une seule valeur de * est fournie, le middleware varie les réponses en fonction de tous les paramètres de chaîne de requête de demande.

Le middleware de mise en cache de réponse doit être activé pour définir la propriété VaryByQueryKeys. Sinon, une exception au runtime est levée. Il n’existe pas d’en-tête HTTP correspondant pour la propriété VaryByQueryKeys. La propriété est une fonctionnalité HTTP gérée par le middleware de mise en cache de réponse. Pour que le middleware serve une réponse en cache, la chaîne de requête et la valeur de chaîne de requête doivent correspondre à une demande précédente. Par exemple, considérez la séquence de requêtes et de résultats indiquée dans le tableau suivant :

La première demande est retournée par le serveur et mise en cache dans un middleware. La deuxième requête est retournée par intergiciel, car la chaîne de requête correspond à la demande précédente. La troisième requête ne se trouve pas dans le cache d’intergiciels, car la valeur de la chaîne de requête ne correspond pas à une demande précédente.

ResponseCacheAttribute est utilisé pour configurer et créer (via IFilterFactory) un Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter. Effectue ResponseCacheFilter le travail de mise à jour des en-têtes HTTP appropriés et des fonctionnalités de la réponse. Le filtre :

• Supprime tous les en-têtes existants pour Vary, Cache-Controlet Pragma.
• Écrit les en-têtes appropriés en fonction des propriétés définies dans ResponseCacheAttribute.
• Mises à jour la fonctionnalité HTTP de mise en cache de la réponse si VaryByQueryKeys est défini.

Vary

Cet en-tête est écrit uniquement lorsque la propriété VaryByHeader est définie. Propriété définie sur la valeur de la propriété Vary. L’exemple suivant utilise la propriété VaryByHeader :

[ApiController]
public class TimeController : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

Affichez les en-têtes de réponse avec Fiddler ou un autre outil. Les en-têtes de réponse sont les suivants :

Cache-Control: public,max-age=30
Vary: User-Agent

Le code précédent nécessite l’ajout des services d’intergiciel de mise en cache de réponse AddResponseCaching à la collection de services et configure l’application pour utiliser l’intergiciel avec la méthode d’extension UseResponseCaching.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

NoStore et Location.None

NoStore remplace la plupart des autres propriétés. Lorsque cette propriété a la valeur true, l’en-tête Cache-Control est défini sur no-store. Si Location est défini sur None :

• Cache-Control a la valeur no-store,no-cache.
• Pragma a la valeur no-cache.

Si NoStore est false et Location est None, Cache-Controlet Pragma sont définis sur no-cache.

NoStore est généralement défini sur true pour les pages d’erreur. Ce qui suit produit des en-têtes de réponse qui indiquent au client de ne pas stocker la réponse.

[Route("api/[controller]/ticks")]
[HttpGet]
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

Le code précédent inclut les en-têtes suivants dans la réponse :

Cache-Control: no-store,no-cache
Pragma: no-cache

Pour appliquer le ResponseCacheAttribute à toutes les réponses de contrôleur MVC ou Razor pages de l’application, ajoutez-le avec un filtre MVC ou Razor un filtre Pages.

Dans une application MVC :

builder.Services.AddControllersWithViews().AddMvcOptions(options => 
    options.Filters.Add(
        new ResponseCacheAttribute
        {
            NoStore = true, 
            Location = ResponseCacheLocation.None
        }));

Pour obtenir une approche qui s’applique aux Razor applications Pages, consultez Ajout ResponseCacheAttribute à la liste de filtres globale MVC ne s’applique pas aux Razor pages (dotnet/aspnetcore #18890). L’exemple fourni dans le commentaire sur le problème a été écrit pour les applications ciblant ASP.NET Core avant la publication des API minimales à la version 6.0. Pour les applications 6.0 ou ultérieures, remplacez l’inscription du service dans l’exemple par builder.Services.AddSingleton... pour Program.cs.

Emplacement et durée

Pour activer la mise en cache, Duration doit être défini sur une valeur positive et Location doit être Any (la valeur par défaut) ou Client. L’infrastructure définit l’en-tête Cache-Control sur la valeur d’emplacement suivie du max-age de la réponse.

Les options Locationde Any et Client traduisent en valeurs d’en-tête Cache-Control de public et private, respectivement. Comme indiqué dans la section NoStore et Location.None , définissez Location en None pour définir les en-têtes Cache-Controlet Pragma sur no-cache.

Location.Any (Cache-Control défini sur public) indique que le client ou tout proxy intermédiaire peut mettre en cache la valeur, y compris intergiciel de mise en cache de réponse.

Location.Client (Cache-Control défini sur private) indique que seul le client peut mettre en cache la valeur. Aucun cache intermédiaire ne doit mettre en cache la valeur, y compris l’intergiciel de mise en cache de la réponse.

Les en-têtes de contrôle du cache fournissent des conseils aux clients et aux proxys intermédiaires quand et comment mettre en cache des réponses. Il n’est pas garanti que les clients et les proxys respectent la RFC 9111 : Mise en cache HTTP. L’intergiciel de mise en cache des réponses suit toujours les règles de mise en cache définies par la spécification.

L’exemple suivant montre les en-têtes générés en définissant Duration et en laissant la valeur par défaut Location :

[Route("api/[controller]/ms")]
[HttpGet]
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public ContentResult GetTimeMS() => Content(
                  DateTime.Now.Millisecond.ToString());

Le code précédent inclut les en-têtes suivants dans la réponse :

Cache-Control: public,max-age=10

Profils de cache

Au lieu de dupliquer les paramètres du cache de réponse sur de nombreux attributs d’action du contrôleur, les profils de cache peuvent être configurés en tant qu’options lors de la configuration de MVC/Razor Pages. Les valeurs trouvées dans un profil de cache référencé sont utilisées comme valeurs par défaut par et ResponseCacheAttribute sont remplacées par toutes les propriétés spécifiées sur l’attribut.

L’exemple suivant montre un profil de cache de 30 secondes :

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();
builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("Default30",
        new CacheProfile()
        {
            Duration = 30
        });
});

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

Le code suivant fait référence au profil de cache Default30 :

[ApiController]
[ResponseCache(CacheProfileName = "Default30")]
public class Time2Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                      DateTime.Now.Ticks.ToString());
}

La réponse d’en-tête résultante par le profil de Default30 cache comprend :

Cache-Control: public,max-age=30

L’attribut [ResponseCache] peut s'appliquer aux éléments suivants :

• Razor Pages : les attributs ne peuvent pas être appliqués aux méthodes de gestionnaire. Les navigateurs utilisés avec les applications d’interface utilisateur empêchent la mise en cache des réponses.
• Contrôleurs MVC.
• Méthodes d’action MVC : les attributs au niveau de la méthode remplacent les paramètres spécifiés dans les attributs au niveau de la classe.

Le code suivant applique l’attribut [ResponseCache] au niveau du contrôleur et de la méthode :

[ApiController]
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Time4Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

    [Route("api/[controller]/ms")]
    [HttpGet]
    [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
    public ContentResult GetTimeMS() => Content(
                      DateTime.Now.Millisecond.ToString());
}

Ressources supplémentaires

• Stockage des réponses dans les caches
• Cache-Control
• Mettre en cache en mémoire dans ASP.NET Core
• Mise en cache distribuée dans ASP.NET Core
• Détecter les modifications avec des jetons de modification dans ASP.NET Core
• Intergiciel de mise en cache des réponses dans ASP.NET Core
• Tag Helper Cache dans ASP.NET Core MVC
• Tag Helper Cache distribué dans ASP.NET Core

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

La mise en cache des réponses réduit le nombre de demandes qu’un client ou un proxy effectue à un serveur web. La mise en cache des réponses réduit également la quantité de travail que le serveur web effectue pour générer une réponse. La mise en cache des réponses est contrôlée par des en-têtes qui spécifient la façon dont vous souhaitez que le client, le proxy et le middleware mettez en cache les réponses.

Participe [ResponseCache] à la définition des en-têtes de mise en cache de réponse. Les clients et les proxys intermédiaires doivent respecter les en-têtes pour la mise en cache des réponses sous RFC 9111 : Mise en cache HTTP.

Pour la mise en cache côté serveur qui suit la spécification de mise en cache HTTP 1.1, utilisez l’intergiciel de mise en cache de réponse. L’intergiciel peut utiliser les propriétés pour définir des [ResponseCache] en-têtes de mise en cache côté serveur.

Mise en cache des réponses basée sur HTTP

RFC 9111 : Mise en cache HTTP décrit le comportement des caches Internet. L’en-tête HTTP principal utilisé pour la mise en cache est Cache-Control, qui est utilisé pour spécifier des directives de cache. Les directives contrôlent le comportement de mise en cache à mesure que les demandes se rendent des clients aux serveurs et que les réponses se rendent des serveurs aux clients. Les requêtes et les réponses transitent par les serveurs proxy, et les serveurs proxy doivent également se conformer à la spécification de mise en cache HTTP 1.1.

Les directives Cache-Control communes sont affichées dans le tableau suivant.

Les autres en-têtes de cache qui jouent un rôle dans la mise en cache sont indiqués dans le tableau suivant.

La mise en cache basée sur HTTP respecte les directives de Cache-Control de requête

RFC 9111 : Mise en cache HTTP (section 5.2. Cache-Control) nécessite un cache pour honorer un en-tête valide Cache-Control envoyé par le client. Un client peut effectuer des requêtes avec une valeur d’en-tête no-cache et forcer le serveur à générer une nouvelle réponse pour chaque requête.

Toujours respecter les en-têtes de requête client Cache-Control est logique si vous envisagez l’objectif de la mise en cache HTTP. Selon la spécification officielle, la mise en cache est destinée à réduire la latence et la surcharge réseau des demandes satisfaisantes sur un réseau de clients, de proxys et de serveurs. Il ne s’agit pas nécessairement d’un moyen de contrôler la charge sur un serveur d’origine.

Il n’existe aucun contrôle de développeur sur ce comportement de mise en cache lors de l’utilisation de intergiciel de mise en cache de réponse, car le middleware respecte la spécification de mise en cache officielle. La prise en charge de la mise en cache de sortie pour mieux contrôler la charge du serveur est une proposition de conception pour une version future de ASP.NET Core. Pour plus d’informations, consultez Ajouter la prise en charge de la mise en cache de sortie (dotnet/aspnetcore #27387).

Autres technologies de mise en cache dans ASP.NET Core

Mise en cache en mémoire

La mise en cache en mémoire utilise la mémoire du serveur pour stocker les données mises en cache. Ce type de mise en cache convient pour un seul serveur ou plusieurs serveurs utilisant l’affinité de session. L’affinité de session est également connue sous le terme de sessions permanentes. L’affinité de session signifie que les demandes d’un client sont toujours routées vers le même serveur pour traitement.

Pour plus d’informations, consultez Mettre en cache en mémoire dans ASP.NET Core et Résoudre les problèmes d’affinité de session Azure Application Gateway.

Cache distribué

Utilisez un cache distribué pour stocker des données en mémoire lorsque l’application est hébergée dans un cloud ou une batterie de serveurs. Le cache est partagé entre les serveurs qui traitent les demandes. Un client peut envoyer une requête gérée par n’importe quel serveur du groupe si les données mises en cache pour le client sont disponibles. ASP.NET Core fonctionne avec les caches distribués SQL Server, Redis et NCache.

Pour plus d’informations, consultez Mise en cache distribuée dans ASP.NET Core.

Tag Helper de cache

Mettez en cache le contenu d’une vue ou d’une Razor page MVC avec le Tag Helper de cache. Le Tag Helper cache utilise la mise en cache en mémoire pour stocker les données.

Pour plus d’informations, consultez assistance des balises de cache dans ASP.NET Core MVC.

Tag Helper Cache distribué

Mettez en cache le contenu à partir d’une vue MVC ou d’une Razor page dans des scénarios cloud distribué ou de batterie de serveurs web avec le tag Helper du cache distribué. Le Tag Helper du cache distribué utilise SQL Server, Redis ou NCache pour stocker des données.

Pour plus d’informations, consultez assistance distribuée des balises de cache dans ASP.NET Core.

Attribut ResponseCache

Le ResponseCacheAttribute spécifie les paramètres nécessaires pour définir les en-têtes appropriés dans la mise en cache des réponses.

VaryByQueryKeys varie la réponse stockée en fonction des valeurs de la liste donnée de clés de requête. Lorsqu’une seule valeur de * est fournie, l’intergiciel varie les réponses en fonction de tous les paramètres de chaîne de requête de requête.

L’intergiciel de mise en cache de réponse doit être activé pour définir la propriété VaryByQueryKeys. Sinon, une exception au runtime est levée. Il n’existe pas d’en-tête HTTP correspondant pour la propriété VaryByQueryKeys. La propriété est une fonctionnalité HTTP gérée par l’intergiciel de mise en cache de réponse. Pour que l’intergiciel serve une réponse mise en cache, la chaîne de requête et la valeur de chaîne de requête doivent correspondre à une demande précédente. Par exemple, considérez la séquence de requêtes et de résultats indiquée dans le tableau suivant.

La première requête est retournée par le serveur et mise en cache dans un intergiciel. La deuxième requête est retournée par intergiciel, car la chaîne de requête correspond à la demande précédente. La troisième requête ne se trouve pas dans le cache d’intergiciels, car la valeur de la chaîne de requête ne correspond pas à une demande précédente.

ResponseCacheAttribute est utilisé pour configurer et créer (via IFilterFactory) un Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter. Effectue ResponseCacheFilter le travail de mise à jour des en-têtes HTTP appropriés et des fonctionnalités de la réponse. Le filtre :

• Supprime tous les en-têtes existants pour Vary, Cache-Controlet Pragma.
• Écrit les en-têtes appropriés en fonction des propriétés définies dans ResponseCacheAttribute.
• Mises à jour la fonctionnalité HTTP de mise en cache de la réponse si VaryByQueryKeys est défini.

Vary

Cet en-tête est écrit uniquement lorsque la propriété VaryByHeader est définie. Propriété définie sur la valeur de la propriété Vary. L’exemple suivant utilise la propriété VaryByHeader :

[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Cache1Model : PageModel
{

À l’aide de l’exemple d’application, affichez les en-têtes de réponse avec les outils réseau du navigateur. Les en-têtes de réponse suivants sont envoyés avec la réponse de page Cache1 :

Cache-Control: public,max-age=30
Vary: User-Agent

NoStore et Location.None

NoStore remplace la plupart des autres propriétés. Lorsque cette propriété a la valeur true, l’en-tête Cache-Control est défini sur no-store. Si Location est défini sur None :

• Cache-Control a la valeur no-store,no-cache.
• Pragma a la valeur no-cache.

Si NoStore est false et Location est None, Cache-Controlet Pragma sont définis sur no-cache.

NoStore est généralement défini sur true pour les pages d’erreur. La page Cache2 de l’exemple d’application produit des en-têtes de réponse qui indiquent au client de ne pas stocker la réponse.

[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public class Cache2Model : PageModel
{

L’exemple d’application retourne la page Cache2 avec les en-têtes suivants :

Cache-Control: no-store,no-cache
Pragma: no-cache

Pour appliquer le ResponseCacheAttribute à toutes les réponses de contrôleur MVC ou Razor pages de l’application, ajoutez-le avec un filtre MVC ou Razor un filtre Pages.

Dans une application MVC :

services.AddMvc().AddMvcOptions(options => 
    options.Filters.Add(
        new ResponseCacheAttribute
        {
            NoStore = true, 
            Location = ResponseCacheLocation.None
        }));

Pour obtenir une approche qui s’applique aux Razor applications Pages, consultez Ajout ResponseCacheAttribute à la liste de filtres globale MVC ne s’applique pas aux Razor pages (dotnet/aspnetcore #18890).

Emplacement et durée

Pour activer la mise en cache, Duration doit être défini sur une valeur positive et Location doit être Any (la valeur par défaut) ou Client. L’infrastructure définit l’en-tête Cache-Control sur la valeur d’emplacement suivie du max-age de la réponse.

Les options Locationde Any et Client traduisent en valeurs d’en-tête Cache-Control de public et private, respectivement. Comme indiqué dans la section NoStore et Location.None , définissez Location en None pour définir les en-têtes Cache-Controlet Pragma sur no-cache.

Location.Any (Cache-Control défini sur public) indique que le client ou tout proxy intermédiaire peut mettre en cache la valeur, y compris intergiciel de mise en cache de réponse.

Location.Client (Cache-Control défini sur private) indique que seul le client peut mettre en cache la valeur. Aucun cache intermédiaire ne doit mettre en cache la valeur, y compris l’intergiciel de mise en cache de la réponse.

Les en-têtes de contrôle du cache fournissent simplement des conseils aux clients et aux proxys intermédiaires quand et comment mettre en cache des réponses. Il n’est pas garanti que les clients et les proxys respectent la RFC 9111 : Mise en cache HTTP. L’intergiciel de mise en cache des réponses suit toujours les règles de mise en cache définies par la spécification.

L’exemple suivant montre le modèle de page Cache3 de l’exemple d’application et les en-têtes générés en définissant Duration et en laissant la valeur par défaut Location :

[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public class Cache3Model : PageModel
{

L’exemple d’application retourne la page Cache3 avec les en-têtes suivants :

Cache-Control: public,max-age=10

Profils de cache

Au lieu de dupliquer les paramètres du cache de réponse sur de nombreux attributs d’action du contrôleur, les profils de cache peuvent être configurés en tant qu’options lors de la configuration de MVC/Razor Pages en Startup.ConfigureServices. Les valeurs trouvées dans un profil de cache référencé sont utilisées comme valeurs par défaut par et ResponseCacheAttribute sont remplacées par toutes les propriétés spécifiées sur l’attribut.

Utilisation d'un profil de cache L’exemple suivant montre un profil de cache de 30 secondes dans l’exemple d’application Startup.ConfigureServices :

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
    services.AddMvc(options =>
    {
        options.CacheProfiles.Add("Default30",
            new CacheProfile()
            {
                Duration = 30
            });
    });
}

Le modèle de page Cache4 de l’exemple d’application fait référence au profil de cache Default30 :

[ResponseCache(CacheProfileName = "Default30")]
public class Cache4Model : PageModel
{

Le ResponseCacheAttribute peut être appliqué à :

• Razor Pages : les attributs ne peuvent pas être appliqués aux méthodes de gestionnaire.
• Contrôleurs MVC.
• Méthodes d’action MVC : les attributs au niveau de la méthode remplacent les paramètres spécifiés dans les attributs au niveau de la classe.

En-tête résultant appliqué à la réponse de page Cache4 par le profil de cache Default30 :

Cache-Control: public,max-age=30

Ressources supplémentaires

• Stockage des réponses dans les caches
• RFC 9111 : Mise en cache HTTP (section 5.2. Cache-Control)
• Mettre en cache en mémoire dans ASP.NET Core
• Mise en cache distribuée dans ASP.NET Core
• Détecter les modifications avec des jetons de modification dans ASP.NET Core
• Intergiciel de mise en cache des réponses dans ASP.NET Core
• Tag Helper Cache dans ASP.NET Core MVC
• Tag Helper Cache distribué dans ASP.NET Core