¿Qué es el encabezado Cache-Control?

Cache-Control es un encabezado de solicitud o respuesta HTTP cuyas directivas rigen el almacenamiento, la vigencia, la revalidación y la reutilización en las cachés. Pueden aplicarse directivas diferentes a los navegadores y a los intermediarios compartidos.

Cache-Control comunica la política mediante directivas separadas por comas que se adjuntan a una solicitud o respuesta HTTP. Las directivas de vigencia determinan cuándo puede reutilizarse el contenido sin contactar con el origen, mientras que las directivas de almacenamiento, validación y ámbito limitan lo que las cachés privadas y compartidas pueden conservar o servir. Las directivas de respuesta son obligatorias para una caché que cumple el estándar, mientras que las directivas de solicitud son orientativas, y una CDN puede ignorar las que permitirían a un cliente forzar una consulta al origen: Google Cloud CDN, por ejemplo, ignora no-cache y max-age en las solicitudes. El encabezado se dirige a todas las cachés de la ruta a la vez y no puede dirigirse a una en particular; por eso, el RFC 9213 define CDN-Cache-Control, un encabezado de respuesta independiente con las mismas directivas que una caché de CDN compatible utiliza en lugar de Cache-Control.

no-cache permite almacenar una respuesta, pero exige validarla correctamente con el origen antes de cada reutilización; no-store indica a todas las cachés, privadas o compartidas, que no almacenen la respuesta en absoluto. El RFC 9111 añade que no-store no es un mecanismo fiable ni suficiente para garantizar la privacidad, por lo que es una instrucción de almacenamiento en caché y no un sustituto del control de acceso.
max-age establece el período de vigencia para todas las cachés; s-maxage lo sustituye en las cachés compartidas, como las CDN, y los navegadores lo ignoran. Para un archivo cuya URL cambia cada vez que cambia su contenido, el patrón de MDN es un max-age largo (su ejemplo es un año) junto con immutable, que indica que la respuesta no se actualizará mientras esté vigente. s-maxage también tiene el significado de proxy-revalidate: una vez que la respuesta caduca, una caché compartida debe revalidarla antes de reutilizarla. Con Origin Cache Control activado, que es la configuración predeterminada en sus planes Free, Pro y Business, Cloudflare no sirve como caducada una respuesta con s-maxage, y Google Cloud CDN documenta lo mismo, por lo que stale-while-revalidate no tiene efecto junto a esa directiva en esos servicios. La solución alternativa documentada por Cloudflare es max-age con stale-while-revalidate más una regla independiente de TTL en el perímetro.
private impide el almacenamiento en cachés compartidas, pero lo permite en la caché del propio navegador, por lo que no equivale a desactivar el almacenamiento en caché. Debe establecerse deliberadamente en las respuestas personalizadas. HTTP, por sí solo, solo impide que las cachés compartidas almacenen una respuesta cuando la solicitud incluye un encabezado Authorization, e incluso en ese caso public, s-maxage o must-revalidate eliminan esa restricción. Una sesión enviada en un encabezado de solicitud Cookie no activa ninguna regla de ese tipo, y el RFC 9111 establece que un encabezado de respuesta Set-Cookie no impide el almacenamiento en caché. Google Cloud CDN no almacena en caché una respuesta que tenga Set-Cookie. Cloudflare, en su nivel de caché predeterminado, tampoco lo hace mientras Origin Cache Control está activado, pero, si está desactivado, puede almacenar la respuesta en caché tras eliminar el encabezado Set-Cookie. En cualquier caso, ese es un comportamiento del proveedor, no una regla de HTTP.
Una respuesta sin Cache-Control aún puede almacenarse en caché. La RFC 9111 permite que una caché asigne un tiempo de vida heurístico a una respuesta que puede almacenarse en caché según criterios heurísticos y no tiene una caducidad explícita; sugiere no superar una fracción del tiempo transcurrido desde Last-Modified. Las CDN aplican su propio tiempo de vida predeterminado cuando el origen no envía ninguno. Los errores se rigen por las mismas reglas: una respuesta final con una vigencia explícita puede almacenarse, por lo que una respuesta 5xx enviada con el max-age de larga duración utilizado para las respuestas correctas puede almacenarse y volver a servirse desde una caché posterior, aunque los códigos de estado que almacena cada CDN dependen del proveedor. Envía no-store en todo lo que no debe almacenarse en caché y no asignes a las respuestas de error los tiempos de vida utilizados para las respuestas correctas. Una CDN también puede almacenar errores en caché según una configuración propia que el encabezado no desactiva: Amazon CloudFront ignora no-store, no-cache y private en las respuestas 500, 502, 503 y 504, y las almacena en caché durante su Error Caching Minimum TTL, que se configura por código de estado y tiene un valor predeterminado de 10 segundos. No almacena estos errores en caché cuando el comportamiento de caché utiliza la política de caché administrada CachingDisabled.
El encabezado del origen no siempre tiene la última palabra en los nodos perimetrales. Amazon CloudFront utiliza el TTL mínimo de la política de caché cuando es mayor que 0, incluso si el origen envió no-cache, no-store o private. Una regla Edge Cache TTL de Cloudflare prevalece sobre s-maxage y las directivas de revalidación, y el modo FORCE_CACHE_ALL de Google Cloud CDN almacena las respuestas correctas en caché independientemente de las directivas del origen. Revisa el TTL y la configuración de anulación de directivas de la CDN antes de confiar en una directiva para impedir que una respuesta se almacene en una caché compartida.

Configura Cache-Control según si una respuesta es pública, privada, inmutable o se actualiza con frecuencia. Las directivas contradictorias o demasiado permisivas pueden exponer datos privados o conservar contenido multimedia caducado.

Cuando Transloadit sirve un archivo transformado a través de Smart CDN, el Robot /file/serve establece el encabezado Cache-Control del resultado, con un tiempo de vida para el navegador en max-age y otro independiente para las cachés compartidas en s-maxage. El parámetro cache_duration del Robot establece ambas directivas en un mismo valor, y su parámetro headers combina tus propios valores de encabezado con los predeterminados, dando prioridad a los tuyos. Para las URL firmadas de Smart CDN, el tiempo de vida efectivo de la caché también está limitado por el tiempo de validez restante de la firma.

La página del Robot enumera los tiempos de vida predeterminados actuales.

Explora las capacidades de entrega de Transloadit

¿Qué es el encabezado Cache-Control?

Cómo funciona el encabezado Cache-Control

Datos clave

Cuándo es importante el encabezado Cache-Control

Cómo ayuda Transloadit con el encabezado Cache-Control

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional