--- title: Cache-Control slug: Web/HTTP/Headers/Cache-Control tags: - Cache-Control - Encabezado general - HTTP - Referencia - encabezado HTTP translation_of: Web/HTTP/Headers/Cache-Control ---
{{HTTPSidebar}}

El encabezado HTTP Cache-Control especifica directivas (instrucciones) para almacenar temporalmente (caching) tanto en peticiones como en respuestas. Una directiva dada en una petición no significa que la misma directiva estar en la respuesta.

Tipo de encabezado {{Glossary("General header", "Encabezado general")}}
{{Glossary("Forbidden header name", "nombre prohibido del encabezado")}} no
{{Glossary("CORS-safelisted response header", "Respuesta del encabezado CORS-safelisted")}} yes

Sintaxis

Las directivas para almacenamiento temporal siguen las siguientes reglas para ser válidas:

Directivas de solicitud de cache

Las directivas estándar Cache-Control que pueden ser usadas por el cliente en una solicitud HTTP.

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

Directivas de solicitud de cache

Las diretivas estándar Cache-Control que pueden ser usadas por el servidor en una respuesta HTTP.

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

Directivas de extensión de Cache-Control

Las directivas de extensión Cache-Control no forman parte de la base del documento estandar para cacheo HTTP. Revisé la tabla de compatibilidad para ver su soporte, los agentes de usuario que no reconocen estas directivas las ignorarán.

Cache-Control: immutable
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>

Directivas

Cacheabilidad

public
La respuesta puede estar almacenada en cualquier memoria cache, incluso si la petición normalmente no es cacheable.
private
La respuesta puede estar almacenada sólo por el cache de un navegador, incluso si la petición es normalmente no cacheable. Si no desea almacenar la respuesta en algún cache, use en su lugar no-store. Esta directiva no es efectiva previniendo el cacheo al almacenar respuestas.
no-cache
La respuesta puede estar almacenada por cualquier cache, incluso si la petición es normalmente no cacheable. Sin embargo, la respuesta almacenada DEBE siempre pasar por una validación con el servidor de origen antes de utilizarse, por lo tanto, no se puede usar no-cache en conjunción con immutable. Si no desea almacenar la respuesta en algún cache, se debe utilizar no-store en su lugar. Esta directiva no es efectiva para prevenir el cacheo al guardar la respuesta.
no-store
La respuesta puede no ser almacenada en cualquier cache. Aunque otras directivas pueden definirla, ésta es la única directiva que se necesita para prevenir el cacheo de respuestas en navegadores modernos. max-age=0 es implícito. Configurando must-revalidate no tiene sentido porque en orden para revalidar se necesita que la respuesta este almacenada en la cache, lo cual no-store previene.
No copie y pege el método específico para Intenet Explorer pre-check=0,post-check=0 si lo ve en línea porque es completamente ignorado, confirmado por el tweet de un desarrollador de Edge.
Deshabilitando Cache vía Cache-Control
no-store
no-cache,no-store,must-revalidate,pre-check=0,post-check=0

Expiración

max-age=<seconds>
La cantidad máxima de tiempo un recurso es considerado reciente. A diferencia de Expires, esta directiva es relativa a el tiempo de la petición.
s-maxage=<seconds>
Anula el encabezado max-age o el Expires, pero solo para caches compartidos (e.g., proxies). Ignorado por caches privados.
max-stale[=<seconds>]
Indica que el cliente aceptará una respuesta tardía. Un valor opciona en segundo indica el límite superior de estancamiento que el cliente aceptará.
min-fresh=<seconds>
Indica que el cliente quiere una respuesta que será reciente por al menos el número específico de segundos.
stale-while-revalidate=<seconds> {{Experimental_Inline}}
Indica que el cliente aceptará una respuesta tardía, mientras asíncronamente revisa por el fondo por una reciente. El valor de los segundos indica que tan largo es el cliente aceptará una respuesta estancada. Ver "Manteniendo las cosas frescas con stale-while-revalidate" para más información.
stale-if-error=<seconds> {{Experimental_Inline}}
Indica que el cliente aceptará una respuesta tardía si la revisión por una resúesta reciente falla. El valor de los segundos indica cuanto tiempo el cliente aceptará la respuesta tardía después de una expiración inicial.

Revalidación y recarga

must-revalidate
Indica que una vez un recurso se vuelve obsoleto, el cache no debe usar su copia obsoleta sin correctamente validar en el servidor de origen.
proxy-revalidate
Similar a must-revalidate, pero solo para caches compartidos (es decir, proxies). Ignorado por caches privados.
immutable
Indica que la respuesta del cuerpo no debería cambiar con el tiempo. El recurso, si no ha expirado, no ha cambiado en el servidor y por lo tanto el cliente no debería enviar una revalidación condicional por ello (es decir, If-None-Match o If-Modified-Since) para revisar por actualizaciones, incluso cuando el usuario explícitamente recarga la página. Los clientes que no son consientes de esta extensión las ignoran deacuerdo a la especificación HTTP. En Firefox, immutable solo es respetada en transacciones https://. Para más información, ver también este árticulo de un blog.

Otros

no-transform
No hay transformaciones o conversiones deberían hacerse al recurso. Los encabezados Content-Encoding, Content-Range, Content-Type no deben ser modificados por un proxy. Un proxy no transparente o una característica de un navegador como podría ser Google's Light Mode, por ejemplo, convierte entre formatos de imagenes con el motivo de guardar espacio del cache o para reducir la cantidad de tráfico en un enlace lento. La directiva no-transform no permite esto.
only-if-cached
Definida por el cliente para indicar "no usar la red" para la respuesta. la cache debería ya sea responder usando una respuesta almacenada, o responder con un código de estado 504. Encabezados condicionales como If-None-Match no deberían ser definidos. No hay efecto si only-if-cached es definido por un servidor como parte de una respuesta.

Ejemplos

Prevención de almacenamiento en caché

Para desactivar el almacenamiento en caché, puede enviar el siguiente encabezado de respuesta. Además, ver también los encabezados Expires y Pragma.

Cache-Control: no-store

Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0

Almacenando temporalmente recursos estáticos

Para los archivos de la aplicación que no cambian, generalmente se puede agregar almacenamiento en caché agresivo enviando el encabezado de respuesta a continuación. Esto incluye, por ejemplo, archivos estáticos servidos por la aplicación, como imágenes, archivos CSS y archivos JavaScript. Además, vea también, el encabezado Expires.

Cache-Control: public, max-age=604800, immutable

Requiriendo revalidación

Especificando no-cache o max-age=0 se indica a los clientes que se puede almacenar temporalmente un recurso y debe revalidarse en cada ocasión antes de utilizarse. Esto significa que las peticiones HTTP ocurren cada vez, pero se pueden saltar la descarga del cuerpo HTTP si el contenido es válido.

Cache-Control: no-cache
Cache-Control: no-cache, max-age=0
Cache-Control: no-cache, max-age=0, stale-while-revalidate=300

Especificaciones

Especificaciones Estado Comentario
{{RFC(8246, "HTTP Immutable Responses")}} IETF RFC
{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}} IETF RFC
{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}} IETF RFC Definición inicial

Compatibilidad de los navegadores

{{Compat("http.headers.Cache-Control")}}

Véase también