En este documento, se explica cómo Cloudflare interpreta los encabezados de control de la memoria caché desde los servidores de origen de los clientes cuando se habilita la función «Origin Cache Control» mediante una Page Rule.

Los encabezados de control de la memoria caché permiten que los administradores informen a Cloudflare sobre la mejor forma de manejar el contenido que ofrece su servidor de origen.

Capacidad de almacenamiento en la memoria caché

Cloudflare adopta decisiones sobre el almacenamiento en la memoria caché en dos fases: una fase de solicitud y una fase de respuesta.

Fase de solicitud

En la fase de solicitud, la dirección URL que solicita el cliente se compara con una lista de extensiones que se pueden almacenar en la memoria caché. Si la solicitud coincide con una extensión de esta lista, analizamos nuestra memoria caché para encontrar el contenido y lo ofrecemos si lo encontramos. Si el contenido está en la memoria caché pero es obsoleto, se intentará revalidar el contenido con el origen antes de enviarle la respuesta al cliente.

Se puede modificar lo que consideramos almacenable en la memoria caché mediante la configuración del «Cache Level» en la aplicación Caché del panel de Cloudflare. Por ejemplo, «Cache Everything» omite la verificación de extensión y todo el contenido se considera almacenable en la memoria caché. También es posible ajustar estas configuraciones mediante una Page Rule.

Fase de respuesta

En el caso de que Cloudflare considere que una solicitud se puede almacenar en la memoria caché, analizaremos primero nuestra memoria caché en varias ubicaciones de la red en busca de contenido. Si el recurso no se encuentra en la memoria caché, Cloudflare realizará una solicitud al servidor de origen para completar la memoria caché.

La respuesta recibida se le envía al cliente que ha realizado la solicitud.

En ese momento, nuestra lógica de la memoria caché analiza la respuesta HTTP recibida del servidor de origen.

Según la interpretación de los encabezados de la solicitud, la respuesta se considerará almacenable en la memoria caché y se escribirá en el disco (que se utilizará para la próxima solicitud del objeto), o se considerará que no se puede almacenar en la memoria caché (por consiguiente, faltará la memoria caché en la siguiente solicitud y se repetirá este proceso).

Directivas de control de la memoria caché

El encabezado del control de la memoria caché puede incluir varias directivas. Si se envían varias directivas juntas, cada una se separa de la otra mediante una coma. Si la directiva incluye un argumento, este sigue a la directiva separada por un signo igual.

En términos generales, las directivas se dividen en agrupaciones amplias en torno a la capacidad de almacenamiento en la memoria caché (¿debería este objeto entrar en una memoria caché?), la caducidad (¿cuánto tiempo debería permanecer en la memoria caché?), la revalidación (¿cómo debería comportarse la memoria caché cuando un objeto ha «caducado»?) y algunos otros aspectos que controlan la forma en que la memoria caché debe gestionar el contenido. 

Capacidad de almacenamiento en la memoria caché

• public
  La directiva de respuesta «public» indica que cualquier memoria caché PUEDE almacenar la respuesta, incluso si la respuesta no se almacena generalmente en la memoria caché o se almacena solo dentro de una memoria caché privada.
• private
  La directiva de respuesta «private» indica que el mensaje de respuesta está destinado a un solo usuario (p. ej., la memoria caché del navegador) y NO DEBE almacenarse en una memoria caché compartida (como Cloudflare o un proxy corporativo).
• no-store
  La directiva de respuesta «no store» indica que cualquier memoria caché (es decir, una memoria caché de cliente o proxy) NO DEBE almacenar ninguna parte de la solicitud o respuesta inmediatas.

Caducidad

• max-age=<seconds>
  La directiva de respuesta «max-age» indica que la respuesta debe considerarse obsoleta después de que su vigencia sea mayor al número de segundos especificado. La vigencia se define como el tiempo en segundos a partir del cual se ha ofrecido el recurso desde el servidor de origen. El segundo argumento es un número entero sin comillas.
• s-maxage=<seconds>
  La directiva de respuesta «s-maxage» indica que, en la memoria caché compartida, la vigencia máxima especificada por esta directiva anula la vigencia máxima especificada, ya sea por la directiva max-age o por el campo del encabezado Expires.  La directiva s-maxage también incluye la semántica de la directiva de respuesta para la revalidación proxy.
• no-cache
  La directiva de respuesta «no-cache» indica que la respuesta NO DEBE utilizarse para solucionar una solicitud posterior sin una validación correcta en el servidor de origen. Como consecuencia, un servidor de origen impide que se utilice una memoria caché para solucionar una solicitud sin contactarlo, incluso con una memoria caché configurada para el envío de respuestas obsoletas.

Revalidación

• must-revalidate
  La directiva de respuesta «must-revalidate» indica que, una vez que la respuesta haya quedado obsoleta, una memoria caché (cliente o proxy) NO DEBE utilizar esta respuesta para solucionar solicitudes posteriores sin una validación correcta en el servidor de origen.
• proxy-revalidate
  La directiva de respuesta «proxy-revalidate» tiene el mismo significado que la directiva de respuesta must-revalidate, con la diferencia de que no se aplica a la memoria caché de clientes privados.
• stale-while-revalidate=<seconds>
  Cuando se encuentra en una respuesta HTTP, la extensión stale-while-revalidate de Cache-Control indica que las memorias caché PUEDEN ofrecer la respuesta en la que aparece después de que se vuelva obsoleta, hasta el número indicado de segundos desde la caducidad del objeto. Nota: si Always Online está habilitado, se ignorará la directiva stale-while-revalidate.
• stale-if-error=<seconds>
  La extensión stale-if-error de Cache-Control indica que cuando se encuentra un error, se PUEDE utilizar una respuesta obsoleta almacenada en la memoria caché para solucionar la solicitud, independientemente de la información actualizada. Nota: si Always Online está habilitada, se ignorará la directiva stale-if-error.

Otras directivas

• no-transform
  La directiva de respuesta «no-transform» indica que un intermediario (independientemente de que se implemente una memoria caché) NO DEBE transformar la carga útil.
• immutable
  Indica a los clientes que el cuerpo de la respuesta no cambiará con el tiempo. Si el recurso no ha caducado, no se modifica en el servidor y, por lo tanto, el cliente no debe enviar una revalidación condicional (p. ej., If-None-Match o If-Modified-Since) para buscar actualizaciones, incluso aunque el usuario actualice la página de manera explícita. Esta directiva no tiene efecto en la memoria caché pública como Cloudflare, pero sí cambia el comportamiento del navegador. 

Ejemplos

Almacenar un recurso estático en la memoria caché

Cache-Control: public, max-age=86400

Asegurarse de que un recurso secreto nunca se almacene en la memoria caché

Cache-Control: no-store

Permitir que un recurso se almacene en los navegadores, pero no en una memoria caché de proxy

Cache-Control: private, max-age=3600

Permitir que un recurso se almacene en la memoria caché de cliente y proxy, pero darle preferencia a la revalidación cada vez que se ofrece el activo

Cache-Control: public, no-cache

Permitir que un recurso se almacene en la memoria caché de proxy, pero SOLICITAR la revalidación por el proxy cada vez que se ofrezca el activo

Cache-Control: public, no-cache, proxy-revalidate

o

Cache-Control: public, s-maxage=0

Permitir que un recurso se almacene en la memoria caché de proxy, pero SOLICITAR la revalidación por cualquier memoria caché cada vez que se ofrezca el activo

Cache-Control: public, no-cache, must-revalidate

Permitir que un recurso se almacene en la memoria caché, pero asegurarse de que el proxy no lo modifique

Cache-Control: public, no-transform

Tenga en cuenta que esta directiva también deshabilitará la transformación, como la compresión gzip o brotli, desde nuestra memoria caché perimetral a sus visitantes si la carga útil original se ha ofrecido sin comprimir.

Permitir que un recurso se almacene en la memoria caché y preferir la revalidación, pero permitir que las respuestas obsoletas se ofrezcan si el servidor de origen es inaccesible o causa errores

Cache-Control: public, max-age=3600, stale-if-error=60

Cloudflare intentará revalidar el contenido con el servidor de origen después de que se haya almacenado en la memoria caché durante 3600 segundos (1 hora). Si el servidor devuelve un error en lugar de las respuestas correctas de revalidación, Cloudflare continuará ofreciendo el recurso obsoleto durante un total de 1 minuto, independientemente de la caducidad del recurso.

Almacenar un recurso de la memoria caché durante diferentes periodos de tiempo en Cloudflare y en el navegador de un visitante

Cache-Control: public, max-age=7200, s-maxage=3600

Almacenar un recurso en la memoria caché y ofrecerlo mientras se está revalidando

Cache-Control: max-age=600, stale-while-revalidate=30

Indica que será válido durante 600 segundos y que puede seguir siendo obsoleto hasta 30 segundos adicionales con el fin de igualar las solicitudes para el mismo recurso mientras se intenta la revalidación sincrónica inicial.

Interacción con otras funciones de Cloudflare

TTL de la memoria caché perimetral

La configuración de una Page Rule del TTL de la memoria caché perimetral anula s-maxage y deshabilita las directivas de revalidación, si las hubiere. El encabezado original de control de la memoria caché se transmite en sentido descendente desde nuestra memoria caché perimetral, incluso si se ha anulado el TTL de la memoria caché perimetral.

TTL de la memoria caché del navegador

La configuración de las Page Rules del TTL de la memoria caché del navegador prevalece sobre la configuración de vigencia máxima que se transmite en sentido descendente desde nuestra memoria caché perimetral, por lo general, a los navegadores de sus visitantes.

Polish

Polish se deshabilita cuando se activa la directiva non-transform.

Gzip y otras compresiones

La compresión se deshabilita cuando se activa la directiva non-transform. Si se comprime el recurso original obtenido del servidor de origen, este activo se le ofrecerá comprimido al visitante. Si el recurso original no está comprimido, la compresión no se realizará.