Intergiciel de mise en cache des réponses dans ASP.NET Core

Par John Luo et Rick Anderson

Cet article explique comment configurer l’intergiciel de mise en cache de sortie dans une application ASP.NET Core. L’intergiciel détermine quand les réponses peuvent être mises en cache, stocke les réponses et traite les réponses du cache. Pour une présentation de la mise en cache HTTP et de l’attribut [ResponseCache] , consultez Mise en cache des réponses.

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.

Configuration

DansProgram.cs, utilisez AddResponseCaching l’ajout des services d’intergiciel de mise en cache de réponse pour la collection de services et configurez l’application pour utiliser l’intergiciel avec la méthode d’extension UseResponseCaching. UseResponseCachingajoute l’intergiciel au pipeline de traitement des requêtes en appelant :

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

Avertissement

UseCors doit être appelé avant UseResponseCaching lors de l’utilisation de l’intergiciel CORS.

L’exemple d’application ajoute des en-têtes pour contrôler la mise en cache sur les requêtes suivantes :

• Cache-Control : met en cache les réponses pouvant être mises en cache pendant une durée maximale de 10 secondes.
• Vary : configure le middleware pour servir une réponse mise en cache uniquement si l’en-tête Accept-Encoding des requêtes suivantes correspond à celui de la demande d’origine.

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

Les en-têtes précédents ne sont pas écrits dans la réponse et sont remplacés lorsqu’un contrôleur, une action ou une page Razor :

• A un attribut [ResponseCache]. Cela s’applique même si aucune propriété n’est définie. Par exemple, l’omission de la propriété VaryByHeader entraîne la suppression de l’en-tête correspondant de la réponse.

Le middleware de mise en cache de réponse met uniquement en cache les réponses du serveur qui entraînent un code état 200 (OK). Toutes les autres réponses, y compris les pages d’erreur, sont ignorées par l’intergiciel.

Avertissement

Les réponses avec du contenu pour les clients authentifiés doivent être marquées comme ne pouvant pas être mises en cache pour empêcher l’intergiciel de stocker et de traiter ces réponses. Pour plus d’informations sur la façon dont l’intergiciel détermine si une réponse peut être mise en cache, consultez Conditions de mise en cache .

Le code précédent ne retourne généralement pas de valeur mise en cache à un navigateur. Utilisez Fiddler, ou un autre outil qui peut définir explicitement des en-têtes de requête et qui est préféré pour tester la mise en cache. Pour plus d'informations, consultez résolution des problèmes dans cet article.

Options

Les options de mise en cache des réponses sont présentées dans le tableau suivant.

Option	Description
MaximumBodySize	La plus grande taille pouvant être mise en cache pour le corps de la réponse, en octets. La valeur par défaut est64 * 1024 * 1024 64 Mo.
SizeLimit	Limite de taille de l’intergiciel du cache de réponse en octets. La valeur par défaut est 100 * 1024 * 1024100 Mo.
UseCaseSensitivePaths	Détermine si les réponses sont mises en cache sur des chemins respectant la casse. La valeur par défaut est false.

L’exemple suivant configure l’intergiciel pour :

• Mettre en cache les réponses avec une taille de corps inférieure ou égale à 1 024 octets.
• Stocker les réponses par chemin d’accès respectant la casse. Par exemple, /page1 et /Page1 sont stockés séparément.

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

Lorsque vous utilisez MVC, des contrôleurs d’API web ou des modèles de page Razor, l’attribut [ResponseCache] spécifie les paramètres nécessaires pour définir les en-têtes appropriés pour la mise en cache des réponses. Le seul paramètre de l’attribut [ResponseCache] qui nécessite strictement le middleware est VaryByQueryKeys, qui ne correspond pas à un en-tête HTTP réel. Pour plus d’informations, consultez Mise en cache des réponses dans ASP.NET Core.

Lorsque vous n’utilisez pas l’attribut [ResponseCache] , la mise en cache des réponses peut être modifiée avec VaryByQueryKeys. Utilisez directement le ResponseCachingFeature à partir de HttpContext.Features :

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

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

L’utilisation d’une valeur unique égale à * dans VaryByQueryKeys varie le cache par tous les paramètres de requête.

En-têtes HTTP utilisés par le middleware de mise en cache de réponse.

Le tableau suivant fournit des informations sur les en-têtes HTTP qui affectent la mise en cache des réponses.

En-tête	Détails
Authorization	La réponse n’est pas mise en cache si l’en-tête existe.
Cache-Control	Le middleware prend uniquement en compte la mise en cache des réponses marquées avec la directive de cache public. Contrôlez la mise en cache avec les paramètres suivants : max-age max-stale† min-fresh must-revalidate no-cache no-store only-if-cached private public s-maxage proxy-revalidate‡ †Si aucune limite n’est spécifiée sur max-stale, le middleware n’effectue aucune action. ‡proxy-revalidate produit le même effet que must-revalidate. Pour plus d’informations, consultez RFC 9111 : Directives de requête.
Pragma	Un en-tête Pragma: no-cachedans la requête produit le même effet queCache-Control: no-cache . Cet en-tête est remplacé par les directives pertinentes dans l’en-têteCache-Control, le cas échéant. Considéré pour la compatibilité descendante avec HTTP/1.0.
Set-Cookie	La réponse n’est pas mise en cache si l’en-tête existe. Tout middleware dans le pipeline de traitement des requêtes qui définit un ou plusieurs cookies empêche le middleware de mise en cache de réponse de mettre en cache la réponse (par exemple, le fournisseur TempData basé sur les cookie).
Vary	L’en-tête Vary est utilisé pour faire varier la réponse mise en cache par un autre en-tête. Par exemple, mettez en cache les réponses par encodage en incluant l’en-tête Vary: Accept-Encoding , qui met en cache les réponses pour les demandes avec des en-têtes Accept-Encoding: gzip et Accept-Encoding: text/plain séparément. Une réponse avec une valeur d’en-tête de *n’est jamais stockée.
Expires	Une réponse considérée comme obsolète par cet en-tête n’est ni stockée ni récupérée, sauf si elle est remplacée par d’autres en-têtesCache-Control.
If-None-Match	La réponse complète est servie à partir du cache si la valeur n’est pas * et si le ETag de la réponse ne correspond à aucune des valeurs fournies. Sinon, une réponse 304 (non modifiée) est traitée.
If-Modified-Since	Si l’en-tête If-None-Match n’est pas présent, une réponse complète est fournie à partir du cache si la date de réponse mise en cache est plus récente que la valeur fournie. Sinon, une réponse 304 - Non modifié est traitée.
Date	Lors de la distribution à partir du cache, l’en-tête Date est défini par l’intergiciel s’il n’a pas été fourni dans la réponse d’origine.
Content-Length	Lors de la distribution à partir du cache, l’en-tête Content-Length est défini par l’intergiciel s’il n’a pas été fourni dans la réponse d’origine.
Age	L’en-tête Age envoyé dans la réponse d’origine est ignoré. L’intergiciel calcule une nouvelle valeur lors de la distribution d’une réponse mise en cache.

La mise en cache respecte les directives de requête de Cache-Control

L’intergiciel respecte les règles de RFC 9111 : Mise en cache HTTP (Section 5.2. Cache-Control). Les règles nécessitent un cache pour respecter un en-tête Cache-Control valide 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. Actuellement, il n’existe aucun contrôle de développeur sur ce comportement de mise en cache lors de l’utilisation du middleware, car le middleware respecte la spécification de mise en cache officielle.

Pour plus de contrôle sur le comportement de mise en cache, explorez d’autres fonctionnalités de mise en cache de ASP.NET Core. Consultez les rubriques suivantes :

• Mettre en cache en mémoire dans ASP.NET Core
• Mise en cache distribuée dans ASP.NET Core
• Tag Helper Cache dans ASP.NET Core MVC
• Tag Helper Cache distribué dans ASP.NET Core

Résolution des problèmes

L’ intergiciel de mise en cache de réponse utilise IMemoryCache, qui a une capacité limitée. Lorsque la capacité est dépassée, le cache de mémoire est compacté.

Si le comportement de mise en cache ne se déroule pas comme prévu, vérifiez que les réponses peuvent être mises en cache et qu’elles peuvent être traitées à partir du cache. Examinez les en-têtes entrants de la requête et les en-têtes sortants de la réponse. Activez la journalisation pour faciliter le débogage.

Lors du test et de la résolution des problèmes de comportement de mise en cache, un navigateur définit généralement des en-têtes de requête qui empêchent la mise en cache. Par exemple, un navigateur peut définir l’en-tête Cache-Control sur no-cache ou max-age=0 lors de l’actualisation d’une page. Fiddler et d’autres outils peuvent définir explicitement des en-têtes de requête et sont préférés pour tester la mise en cache.

Conditions de mise en cache

• La requête doit donner lieu à une réponse du serveur avec un code de statut 200 (OK).
• La méthode de requête doit être GET ou HEAD.
• L’intergiciel de mise en cache de réponse doit être placé avant les intergiciels qui nécessitent une mise en cache. Pour plus d’informations, consultez Intergiciel (middleware) ASP.NET Core.
• L’en-tête Authorization ne doit pas être présent.
• Les paramètres d’en-tête Cache-Control doivent être valides et la réponse doit être marquée public et non private.
• L’en-tête Pragma: no-cache ne doit pas être présent si l’en-tête Cache-Control n’est pas présent, car l’en-tête Cache-Control remplace l’en-tête Pragma lorsqu’il est présent.
• L’en-tête Set-Cookie ne doit pas être présent.
• Les paramètres d’en-têteVary doivent être valides et non égaux à *.
• La valeur Content-Length d’en-tête (si définie) doit correspondre à la taille du corps de la réponse.
• IHttpSendFileFeature n’est pas utilisé.
• La réponse ne doit pas être obsolète comme spécifié par l’en-tête Expires et les directives de cache max-age et s-maxage.
• La mise en mémoire tampon de réponse doit réussir. La taille de la réponse doit être inférieure à laSizeLimit configurée ou par défaut . La taille de la réponse doit être inférieure à la MaximumBodySizeconfigurée ou par défaut .
• La réponse doit être mise en cache selon RFC 9111 : Mise en cache HTTP. Par exemple, la directive no-store ne doit pas exister dans les champs d’en-tête de requête ou de réponse. Pour plus d’informations , consultez RFC 9111 : Mise en cache HTTP (Section 3 : Stockage des réponses dans les caches ).

Remarque

Le système Antiforgery pour générer des jetons sécurisés pour empêcher les attaques CSRF (falsification des requêtes intersites) définit les en-têtes Cache-Controlet Pragma sur no-cache afin que les réponses ne soient pas mises en cache. Pour plus d’informations sur la désactivation des jetons Antiforgery pour les éléments de formulaire HTML, consultez Empêcher les attaques par falsification de requête intersites (XSRF/CSRF) dans ASP.NET Core.

Ressources supplémentaires

• Affichez ou téléchargez l’exemple de code (procédure de téléchargement)
• Source GitHub pour IResponseCachingPolicyProvider
• Source GitHub pour IResponseCachingPolicyProvider
• Démarrage d’une application dans ASP.NET Core
• Intergiciel (middleware) ASP.NET Core
• 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
• 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