Middleware de almacenamiento en caché de respuestas en ASP.NET Core

Por John Luo y Rick Anderson

En este artículo se explica cómo configurar el middleware de almacenamiento en caché de respuestas en una aplicación de ASP.NET Core. El middleware determina cuándo las respuestas son almacenables en caché, almacena las respuestas y atiende las respuestas de la memoria caché. Para obtener una introducción al almacenamiento en caché HTTP y el atributo [ResponseCache], consulte Almacenamiento en caché de respuesta.

Middleware de almacenamiento en caché de respuestas:

• Habilita el almacenamiento en caché de respuestas del servidor basadas en encabezados de caché HTTP. Implementa la semántica de almacenamiento en caché HTTP estándar. Cachés basadas en encabezados de caché HTTP, como los servidores proxy.
• Normalmente no se recomienda en aplicaciones de interfaz de usuario, como Razor Pages, porque los exploradores suelen establecer encabezados de solicitud que impiden el almacenamiento en caché. El almacenamiento en caché de resultados, que está disponible en ASP.NET Core 7.0 y versiones posteriores, beneficia a las aplicaciones de interfaz de usuario. Con el almacenamiento en caché de resultados, la configuración decide qué se debe almacenar en caché independientemente de los encabezados HTTP.
• Puede ser beneficioso para las solicitudes públicas de API HEAD o GET de los clientes en los que se cumplen las condiciones para el almacenamiento en caché.

Para probar el almacenamiento en caché de respuestas, use Fiddler u otra herramienta que pueda establecer explícitamente encabezados de solicitud. Se prefiere establecer explícitamente los encabezados para probar el almacenamiento en caché. Para más información, consulte Solución de problemas.

Configuración

En Program.cs añada los servicios de Middleware de almacenamiento en caché de respuesta AddResponseCaching a la colección de servicios y configure la aplicación para usar el middleware con el método de extensión UseResponseCaching. UseResponseCaching agrega el middleware a la canalización de procesamiento de solicitudes:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

Advertencia

UseCors debe llamarse antes que UseResponseCaching al usar middleware CORS.

La aplicación de ejemplo agrega encabezados para controlar el almacenamiento en caché en las solicitudes posteriores:

• Cache-Control: almacena en caché las respuestas que se pueden almacenar en caché durante un máximo de 10 segundos.
• Vary: configura el middleware para atender una respuesta almacenada en caché solo si el encabezado Accept-Encoding de las solicitudes posteriores coincide con el de la solicitud original.

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

Los encabezados anteriores no se escriben en la respuesta y se invalidan cuando un controlador, una acción o Razor Page:

• Tiene un atributo [ResponseCache]. Esto se aplica incluso si no se establece una propiedad. Por ejemplo, si se omite la propiedad VaryByHeader, el encabezado correspondiente se quitará de la respuesta.

El middleware de almacenamiento en caché de respuesta solo almacena en caché las respuestas del servidor que dan como resultado un código de estado 200 (CORRECTO). El middleware omite cualquier otra respuesta, incluidas las páginas de error.

Advertencia

Las respuestas que contienen contenido para los clientes autenticados deben marcarse como no almacenables en caché para evitar que el middleware almacene y sirva esas respuestas. Consulte Condiciones para el almacenamiento en caché para obtener más información sobre cómo determina el middleware si una respuesta se puede almacenar en caché.

Normalmente, el código anterior no devuelve un valor almacenado en caché a un explorador. Use Fiddler, Postman u otra herramienta que pueda establecer explícitamente encabezados de solicitud y se prefiere para probar el almacenamiento en caché. Para obtener más información, consulte Solución de problemas en este artículo.

Opciones

Las opciones de almacenamiento en caché de respuesta se muestran en la tabla siguiente.

Opción	Descripción
MaximumBodySize	El mayor tamaño que se puede almacenar en caché para el cuerpo de la respuesta en bytes. El valor predeterminado es 64 * 1024 * 1024 (64 MB).
SizeLimit	Límite de tamaño del middleware de caché de respuesta en bytes. El valor predeterminado es 100 * 1024 * 1024 (100 MB).
UseCaseSensitivePaths	Determina si las respuestas se almacenan en caché en rutas de acceso que distinguen mayúsculas de minúsculas. El valor predeterminado es false.

En el ejemplo siguiente se configura el middleware para:

• Almacenar en caché las respuestas con un tamaño de cuerpo menor o igual a 1024 bytes.
• Almacene las respuestas por rutas de acceso que distinguen mayúsculas de minúsculas. Por ejemplo, /page1 y /Page1 se almacenan por separado.

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

Cuando se usa MVC, controladores de API web o modelos de página de Razor Pages, el atributo [ResponseCache] especifica los parámetros necesarios para establecer los encabezados adecuados para el almacenamiento en caché de respuestas. El único parámetro del atributo [ResponseCache] que requiere estrictamente el middleware es VaryByQueryKeys, que no corresponde a un encabezado HTTP real. Para más información, consulte Almacenamiento en caché de respuestas en ASP.NET Core.

Cuando no se usa el atributo [ResponseCache], el almacenamiento en caché de respuestas puede variar con VaryByQueryKeys. Use directamente el ResponseCachingFeature desde HttpContext.Features:

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

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

El uso de un único valor igual a * en VaryByQueryKeys varía la memoria caché por todos los parámetros de consulta de solicitud.

Encabezados HTTP usados por middleware de almacenamiento en caché de respuestas

En la tabla siguiente se proporciona información sobre los encabezados HTTP que afectan al almacenamiento en caché de respuestas.

Encabezado	Detalles
Authorization	La respuesta no se almacena en caché si el encabezado existe.
Cache-Control	El middleware solo considera la posibilidad de almacenar en caché las respuestas marcadas con la directiva de caché public. Controle el almacenamiento en caché con los parámetros siguientes: max-age max-stale† min-fresh must-revalidate sin caché no-store only-if-cached privado público s-maxage proxy-revalidate‡ †Si no se especifica ningún límite en max-stale, el middleware no realiza ninguna acción. ‡proxy-revalidate tiene el mismo efecto que must-revalidate. Para obtener más información, consulte RFC 9111: Directivas de solicitud.
Pragma	Un encabezado Pragma: no-cache de la solicitud genera el mismo efecto que Cache-Control: no-cache. Este encabezado se invalida mediante las directivas pertinentes del encabezado Cache-Control si están presentes. Se considera para la compatibilidad con versiones anteriores con HTTP/1.0.
Set-Cookie	La respuesta no se almacena en caché si el encabezado existe. Cualquier middleware de la canalización de procesamiento de solicitudes que establece una o varias cookie impide que el middleware de almacenamiento en caché de respuesta almacene en caché la respuesta (por ejemplo, el proveedor TempData basado en cookie).
Vary	Otro encabezado usa el encabezado Vary para variar la respuesta almacenada en caché. Por ejemplo, almacene en caché las respuestas mediante la codificación con la inclusión del encabezado Vary: Accept-Encoding, que almacena en caché las respuestas para las solicitudes con encabezados Accept-Encoding: gzip y Accept-Encoding: text/plain por separado. Nunca se almacena una respuesta con un valor de encabezado de *.
Expires	Una respuesta considerada obsoleta por este encabezado no se almacena ni recupera a menos que otros encabezados Cache-Control la invaliden.
If-None-Match	La respuesta completa se sirve desde la memoria caché si el valor no es * y el ETag de la respuesta no coincide con ninguno de los valores proporcionados. De lo contrario, se proporciona una respuesta 304 (No modificada).
If-Modified-Since	Si el encabezado If-None-Match no está presente, se proporciona una respuesta completa desde la memoria caché si la fecha de respuesta almacenada en caché es más reciente que el valor proporcionado. De lo contrario, se sirve una respuesta 304 - No modificada .
Date	Al servir desde la memoria caché, el middleware establece el encabezado Date si no se proporcionó en la respuesta original.
Content-Length	Al servir desde la memoria caché, el middleware establece el encabezado Content-Length si no se proporcionó en la respuesta original.
Age	Se omite el encabezado Age enviado en la respuesta original. El middleware calcula un nuevo valor al atender una respuesta almacenada en caché.

El almacenamiento en caché respeta las directivas de solicitud Cache-Control

El middleware respeta las reglas de RFC 9111: Almacenamiento en caché HTTP (sección 5.2. Cache-Control). Las reglas requieren una memoria caché para respetar un encabezado Cache-Control válido enviado por el cliente. En la especificación, un cliente puede realizar solicitudes con un valor de encabezado no-cache y forzar al servidor a generar una nueva respuesta para cada solicitud. Actualmente, no hay ningún control del desarrollador sobre este comportamiento de almacenamiento en caché al usar el middleware porque el middleware se adhiere a la especificación de almacenamiento en caché oficial.

Para obtener más control sobre el comportamiento del almacenamiento en caché, explore otras características de almacenamiento en caché de ASP.NET Core. Vea los siguientes temas:

• Caché en memoria en ASP.NET Core
• Almacenamiento en caché distribuido en ASP.NET Core
• Asistente de etiquetas de caché en ASP.NET Core MVC
• Asistente de etiquetas de caché distribuida en ASP.NET Core

Solución de problemas

El middleware de almacenamiento en caché de respuesta usa IMemoryCache, que tiene una capacidad limitada. Cuando se supera la capacidad, se compacta la memoria caché.

Si el comportamiento de almacenamiento en caché no es el esperado, confirme que las respuestas se pueden almacenar en caché y que se pueden atender desde la memoria caché. Examine los encabezados entrantes de la solicitud y los encabezados salientes de la respuesta. Habilite el registro para ayudar con la depuración.

Al probar y solucionar problemas de comportamiento de almacenamiento en caché, un explorador suele establecer encabezados de solicitud que impiden el almacenamiento en caché. Por ejemplo, un explorador web puede establecer el encabezado Cache-Control en no-cache o en max-age=0 al actualizar una página. Fiddler, Postman y otras herramientas pueden establecer explícitamente encabezados de solicitud y se prefieren para probar el almacenamiento en caché.

Condiciones para el almacenamiento en caché

• La solicitud debe dar lugar a una respuesta del servidor con un código de estado 200 (CORRECTO).
• El método de solicitud debe ser GET o HEAD.
• El middleware de almacenamiento en caché de respuesta debe colocarse antes del middleware que requiera almacenamiento en caché. Para obtener más información, consulte Middleware de ASP.NET Core.
• El encabezado Authorization no debe estar presente.
• Los parámetros de encabezado Cache-Control deben ser válidos y la respuesta debe marcarse como public y no marcarse como private.
• El encabezado Pragma: no-cache no debe estar presente si el encabezado Cache-Control no está presente, ya que el encabezado Cache-Control invalida el encabezado Pragma cuando está presente.
• El encabezado Set-Cookie no debe estar presente.
• Los parámetros de encabezado Vary deben ser válidos y no iguales a *.
• El valor del encabezado Content-Length (si se establece) debe coincidir con el tamaño del cuerpo de la respuesta.
• El IHttpSendFileFeature no se utiliza.
• La respuesta no debe estar obsoleta según lo especificado por el encabezado Expires y las directivas de caché max-age y s-maxage.
• El almacenamiento en búfer de respuesta debe ser correcto. El tamaño de la respuesta debe ser menor que el SizeLimit configurado o predeterminado. El tamaño del cuerpo de la respuesta debe ser menor que el MaximumBodySizeconfigurado o predeterminado.
• La respuesta debe almacenarse en caché según RFC 9111: almacenamiento en caché HTTP. Por ejemplo, la directiva no-store no debe existir en los campos de encabezado de solicitud o respuesta. Consulte RFC 9111: Almacenamiento en caché HTTP (sección 3: Almacenamiento de respuestas en caché para obtener más información.

Nota

El sistema antifalsificación para generar tokens seguros para evitar ataques de falsificación de solicitudes entre sitios (CSRF) establece los encabezados Cache-Control y Pragma en no-cache para que las respuestas no se almacenen en caché. Para obtener información sobre cómo deshabilitar tokens antifalsificación para elementos de formulario HTML, vea Evitar ataques de falsificación de solicitudes entre sitios (XSRF/CSRF) en ASP.NET Core.

Recursos adicionales

• Vea o descargue el código de ejemplo (cómo descargarlo)
• Origen de GitHub para IResponseCachingPolicyProvider
• Origen de GitHub para IResponseCachingPolicyProvider
• Inicio de la aplicación en ASP.NET Core
• Middleware de ASP.NET Core
• Caché en memoria en ASP.NET Core
• Almacenamiento en caché distribuido en ASP.NET Core
• Detección de cambios con tokens de cambio en ASP.NET Core
• Almacenamiento en caché de respuestas de ASP.NET Core
• Asistente de etiquetas de caché en ASP.NET Core MVC
• Asistente de etiquetas de caché distribuida en ASP.NET Core