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

Par Rick Anderson et Kirk Larkin

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.

Directive	Action
public	Un cache peut stocker la réponse.
private	La réponse ne doit pas être stockée par un cache partagé. Un cache privé peut stocker et réutiliser la réponse.
max-age	Le client n’accepte pas une réponse dont l’âge est supérieur au nombre de secondes spécifié. Exemples : max-age=60 (60 secondes), max-age=2592000 (1 mois)
no-cache	Sur les demandes : un cache ne doit pas utiliser de réponse stockée pour répondre à la demande. Le serveur d’origine régénère la réponse pour le client, et l’intergiciel met à jour la réponse stockée dans son cache. Sur les réponses : la réponse ne doit pas être utilisée pour une requête ultérieure sans validation sur le serveur d’origine.
no-store	Sur les demandes : un cache ne doit pas stocker la demande. Sur les réponses : un cache ne doit stocker aucune partie de la réponse.

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

En-tête	Fonction
Age	Estimation du temps, en secondes, depuis que la réponse a été générée ou validée avec succès sur le serveur d’origine.
Expires	Heure après laquelle la réponse est considérée comme obsolète.
Pragma	Existe pour la compatibilité descendante avec les caches HTTP/1.0 pour définir le comportement no-cache. Si l’en-tête Cache-Control est présent, l’en-tête Pragma est ignoré.
Vary	Spécifie qu’une réponse mise en cache ne doit pas être envoyée, sauf si tous les champs d’en-tête Vary correspondent à la demande d’origine de la réponse mise en cache et à la nouvelle requête.

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.

Avertissement

Désactivez la mise en cache pour le contenu qui contient des informations pour les clients authentifiés. La mise en cache ne doit être activée que pour le contenu qui ne change pas en fonction de l’identity d’un utilisateur ou si un utilisateur est connecté.

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 :

Requête	Retourné à partir de
http://example.com?key1=value1	Serveur
http://example.com?key1=value1	Middleware
http://example.com?key1=NewValue	Serveur

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