Información general sobre el almacenamiento en caché

Una respuesta que se puede almacenar en caché es una respuesta HTTP que Cloud CDN puede almacenar y recuperar rápidamente, lo que permite que los tiempos de carga sean más rápidos. No todas las respuestas HTTP se pueden almacenar en caché.

Modos de caché

Con los modos de caché, puede controlar los factores que determinan si Cloud CDN almacena en caché su contenido.

Cloud CDN ofrece tres modos de caché que definen cómo se almacenan en caché las respuestas, si Cloud CDN respeta las directivas de caché enviadas por el origen y cómo se aplican los TTL de caché.

En la siguiente tabla se muestran los modos de caché disponibles:

Modo de caché Comportamiento
CACHE_ALL_STATIC Almacena en caché automáticamente las respuestas correctas con contenido estático que, de lo contrario, no se podría almacenar en caché. También se almacenan en caché las respuestas de origen que definen directivas de almacenamiento en caché válidas.

Este comportamiento es el predeterminado para los back-ends habilitados para Cloud CDN que se crean con la interfaz de línea de comandos de Google Cloud o la API REST.
USE_ORIGIN_HEADERS Requiere respuestas de origen correctas para definir directivas de caché válidas y encabezados de almacenamiento en caché válidos. Las respuestas correctas sin estas directivas se reenvían desde el origen.
FORCE_CACHE_ALL Almacena en caché incondicionalmente las respuestas correctas, anulando cualquier directiva de caché definida por el origen. Este modo no es adecuado si el backend sirve contenido privado y por usuario (información de identificación personal), como HTML dinámico o respuestas de API.

Las respuestas de error se pueden almacenar en caché incluso si no hay directivas de caché válidas.

Antes de definir el modo de caché en FORCE_CACHE_ALL, ten en cuenta los siguientes comportamientos:

  • En el caso de las URLs o cookies firmadas, FORCE_CACHE_ALL anula la antigüedad máxima especificada mediante el ajuste Antigüedad máxima de la entrada de caché en la consola Google Cloud o la opción gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL cambia el tiempo de vida (TTL) de cualquier contenido almacenado en caché anteriormente. Este cambio puede hacer que algunas entradas que antes se consideraban recientes (porque tenían TTLs más largos en los encabezados de origen) se consideren obsoletas, y que algunas entradas que antes se consideraban obsoletas se consideren recientes.

  • FORCE_CACHE_ALL anula las directivas de caché (Cache-Control y Expires), pero no anula otros encabezados de respuesta de origen. En concreto, un encabezado Vary puede suprimir el almacenamiento en caché aunque el modo de caché sea FORCE_CACHE_ALL. Para obtener más información, consulta Encabezados Vary.

Para obtener instrucciones de configuración, consulta el artículo Configurar el modo de caché.

Contenido estático

El contenido estático es el que siempre es el mismo, incluso cuando acceden diferentes usuarios. El CSS que usas para dar estilo a tu sitio, JavaScript para proporcionar interactividad, vídeo y contenido de imagen normalmente no cambian para cada usuario en una URL determinada (clave de caché) y, por lo tanto, se benefician de estar en caché en la red perimetral global de Cloud CDN.

Si configuras el modo de caché como CACHE_ALL_STATIC y una respuesta no tiene directivas de almacenamiento en caché explícitas en los encabezados Cache-Control o Expires, Cloud CDN almacena en caché automáticamente esa respuesta en los siguientes casos:

  • Recursos web, incluidos CSS (text/css), JavaScript (application/javascript) y todas las fuentes web, incluido WOFF2 (font/woff2)
  • Imágenes, incluidos JPEG (image/jpg) y PNG (image/png)
  • Vídeos, incluidos H.264, H.265 y MP4 (video/mp4)
  • Archivos de audio, incluidos MP3 (audio/mpeg) y MP4 (audio/mp4)
  • Documentos formateados, incluidos PDF (application/pdf)

En la siguiente tabla puedes ver un resumen.

Categoría tipos MIME
Recursos web text/css text/ecmascript text/javascript application/javascript
Fuentes Cualquier Content-Type que coincida con font/*
Imágenes Cualquier Content-Type que coincida con image/*
Vídeos Cualquier Content-Type que coincida con video/*
Audio Cualquier Content-Type que coincida con audio/*
Tipos de documentos con formato application/pdf y application/postscript

Cloud CDN inspecciona el encabezado de respuesta HTTP Content-Type, que refleja el tipo MIME del contenido que se está sirviendo.

Ten en cuenta lo siguiente:

  • El software del servidor web de tu origen debe definir el Content-Type para cada respuesta. Muchos servidores web definen automáticamente el encabezado Content-Type, incluidos NGINX, Varnish y Apache.

  • Cloud Storage define el encabezado Content-Type automáticamente cuando usas la Google Cloud consola o la CLI de Google Cloud para subir contenido.

  • Cloud Storage siempre proporciona un encabezado Cache-Control a Cloud CDN. Si no se elige ningún valor explícitamente, se envía un valor predeterminado. Por lo tanto, todas las respuestas correctas de Cloud Storage se almacenan en caché según los valores predeterminados de Cloud Storage, a menos que ajuste explícitamente los metadatos de control de caché de los objetos de Cloud Storage o utilice el modo FORCE_CACHE_ALL para anular los valores enviados por Cloud Storage.

  • Si quieres almacenar en caché los tipos de contenido text/html y application/json, debes definir encabezados Cache-Control explícitos en la respuesta y tener cuidado de no almacenar en caché por error los datos de un usuario y ofrecérselos a todos los usuarios.

Si una respuesta se puede almacenar en caché en función de su tipo MIME, pero tiene un encabezado de respuesta Cache-Control de private o no-store, o un encabezado Set-Cookie, no se almacena en caché. Para obtener más información, consulta las reglas de almacenamiento en caché.

Otros tipos de contenido, como HTML (text/html) y JSON (application/json), no se almacenan en caché de forma predeterminada para las respuestas correctas. Este tipo de respuestas suelen ser dinámicas (por usuario). Por ejemplo, carritos de la compra, páginas de productos con personalización para el usuario y respuestas de APIs autenticadas. Sin embargo, si está habilitado el almacenamiento en caché negativo, es posible que se almacenen en caché para determinados códigos de estado.

Cloud CDN no usa extensiones de archivo en la ruta de la URL para determinar si una respuesta se puede almacenar en caché, ya que muchas respuestas válidas que se pueden almacenar en caché no se reflejan en las URLs.

Contenido que se puede almacenar en caché

Cloud CDN almacena en caché las respuestas que cumplen todos los requisitos de esta sección. Algunos de estos requisitos se especifican en RFC 7234, mientras que otros son específicos de Cloud CDN.

Cloud CDN puede cambiar periódicamente el conjunto exacto de condiciones en las que almacena contenido en caché. Si quiere evitar explícitamente que Cloud CDN almacene en caché su contenido, siga las directrices de RFC 7234 para determinar cómo especificar una respuesta que no se pueda almacenar en caché. Consulta también la sección Contenido no almacenable en caché basado en encabezados de origen.

Cloud CDN almacena las respuestas en caché si se cumplen todas las condiciones siguientes.

Atributo Requisito
Publicado por Servicio de backend, segmento de backend o backend externo con Cloud CDN habilitado
En respuesta a Solicitud de GET
Código de estado

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 o 501.
Actualización

La respuesta tiene un encabezado Cache-Control con una directiva max-age o s-maxage, o un encabezado Expires con una marca de tiempo futura.

En el caso de las respuestas almacenables en caché sin antigüedad (por ejemplo, con no-cache), se debe proporcionar explícitamente la directiva public.

En el modo de caché CACHE_ALL_STATIC, si no hay directivas de actualización, se puede almacenar en caché una respuesta correcta con un tipo de contenido estático.

Con el modo de caché FORCE_CACHE_ALL, cualquier respuesta correcta se puede almacenar en caché. Esto puede dar lugar a que se almacene en caché contenido privado y por usuario. Solo debes definir FORCE_CACHE_ALL en backends que no estén sirviendo contenido privado o dinámico (por ejemplo, en segmentos de Cloud Storage).

Si el almacenamiento en caché negativo está habilitado y el código de estado coincide con uno para el que se especifica un TTL, la respuesta se puede almacenar en caché, aunque no tenga directivas de actualización explícitas.
Contenido

En el caso de los orígenes HTTP/1, la respuesta debe contener un encabezado Content-Length, Content-Range o Transfer-Encoding: chunked válido.

En el caso de los orígenes que usan versiones más avanzadas del protocolo HTTP (HTTP/2 y posteriores), no es necesario que la respuesta tenga estos encabezados.
Tamaño Menor o igual que el tamaño máximo.

En el caso de las respuestas con tamaños entre 10 MiB y 100 GiB, consulta las restricciones de almacenamiento en caché adicionales que se describen en las solicitudes de intervalo de bytes.

En el caso de los segmentos de backend de Cloud Storage, sigue estas sugerencias adicionales:

De forma predeterminada, cuando un objeto es público y no especifica metadatos Cache-Control, Cloud Storage le asigna un encabezado Cache-Control: public, max-age=3600. Puedes definir valores diferentes mediante los Cache-Controlmetadatos.

Para ver un ejemplo de cómo configurar un balanceador de carga de aplicación externo con un segmento de backend, consulta Configurar Cloud CDN con un segmento de backend.

Tamaño máximo

Cloud CDN aplica un tamaño máximo a cada respuesta. Las respuestas con un cuerpo mayor que el tamaño máximo no se almacenan en caché, pero se siguen enviando al cliente.

El tamaño máximo varía en función de si el servidor de origen admite solicitudes de intervalo de bytes.

El servidor de origen admite solicitudes de intervalo de bytes El servidor de origen no admite solicitudes de intervalo de bytes
100 GiB (107.374.182.400 bytes) 10 MiB (10.485.760 bytes)

Casi todos los servidores web modernos (incluidos NGINX, Apache y Varnish) admiten solicitudes de intervalo de bytes.

Contenido que no se puede almacenar en caché en función de los encabezados de origen

Hay comprobaciones que bloquean el almacenamiento en caché de las respuestas. Cloud CDN puede cambiar periódicamente el conjunto exacto de condiciones en las que almacena contenido en caché, por lo que, si quieres evitar explícitamente que Cloud CDN almacene tu contenido en caché, sigue las directrices del estándar (RFC 7234) para determinar cómo especificar una respuesta que no se pueda almacenar en caché.

Cloud CDN no almacena en caché una respuesta si no cumple los requisitos de contenido que se puede almacenar en caché o si se cumple alguna de las siguientes condiciones.

Atributo Requisito
Publicado por Servicio de backend o backend externo que no tiene Cloud CDN habilitado
Cookie Tiene un encabezado Set-Cookie
Encabezado Vary Tiene un valor distinto de Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin o uno de los encabezados configurados para formar parte de los ajustes de clave de caché.
Directiva de respuesta La respuesta tiene un encabezado Cache-Control con la directiva no-store o private (a menos que se use el modo de caché FORCE_CACHE_ALL, en cuyo caso se ignora el encabezado Cache-Control).
Directiva de solicitud La solicitud tiene una directiva Cache-Control: no-store
Solicitar autorización La solicitud tiene un encabezado Authorization, a menos que la respuesta Cache-Control lo anule.
Tamaño Supera el tamaño máximo

Si Cache-Control: no-store o private están presentes, pero el contenido sigue almacenándose en caché, se debe a uno de los siguientes motivos:

  • La firma de URLs está configurada.
  • El modo de caché de Cloud CDN se ha configurado para forzar el almacenamiento en caché de todas las respuestas.

Evitar el almacenamiento en caché

Para evitar que la información privada se almacene en caché en las cachés de Cloud CDN, haz lo siguiente:

  1. Asegúrate de que el modo de caché de Cloud CDN no esté configurado en el modo FORCE_CACHE_ALL, que almacena en caché de forma incondicional todas las respuestas correctas.
  2. Incluye un encabezado Cache-Control: private en las respuestas que no deban almacenarse en las cachés de Cloud CDN o un encabezado Cache-Control: no-store en las respuestas que no deban almacenarse en ninguna caché, ni siquiera en la de un navegador web.
  3. No firmes URLs que proporcionen acceso a información privada. Cuando se accede al contenido mediante una URL firmada, es posible que se pueda almacenar en caché, independientemente de las directivas Cache-Control de la respuesta.
  4. En el caso de las solicitudes de origen (relleno de caché) que incluyen el encabezado de solicitud Authorization, Cloud CDN solo almacena en caché las respuestas que incluyen las directivas de control de caché public, must-revalidate o s-maxage cuando el modo de caché está definido como USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. De esta forma, se evita que se almacene en caché por error contenido por usuario y contenido que requiera autenticación. El modo de caché de FORCE_CACHE_ALL no tiene esta restricción.

Encabezados de respuesta personalizados

Con los encabezados de respuesta personalizados, puedes especificar encabezados que el balanceador de carga de aplicaciones clásico añade a las respuestas procesadas en el proxy. Los encabezados de respuesta personalizados te permiten reflejar el estado de la caché a tus clientes, los datos geográficos de los clientes y tus propios encabezados de respuesta estáticos.

Para obtener instrucciones, consulta el artículo Configurar encabezados de respuesta personalizados.

Claves de caché

Cada entrada de la caché de Cloud CDN se identifica mediante una clave de caché. Cuando llega una solicitud a la caché, esta convierte el URI de la solicitud en una clave de caché y, a continuación, la compara con las claves de las entradas almacenadas en caché. Si encuentra una coincidencia, la caché devuelve el objeto asociado a esa clave.

En el caso de los servicios de backend, Cloud CDN usa de forma predeterminada el URI de solicitud completo como clave de caché. Por ejemplo, https://example.com/images/cat.jpg es el URI completo de una solicitud concreta del objeto cat.jpg. Esta cadena se usa como clave de caché predeterminada. Solo se mostrarán resultados que coincidan exactamente con esta cadena. Las solicitudes de http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

En el caso de los backend buckets, la clave de caché predeterminada se compone del URI sin el protocolo ni el host. De forma predeterminada, solo los parámetros de consulta que conoce Cloud Storage se incluyen en la clave de caché (por ejemplo, "generation").

Por lo tanto, para un determinado contenedor de backend, los siguientes URIs se resuelven en el mismo objeto almacenado en caché:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Puede cambiar qué partes del URI se usan en la clave de caché. Aunque el nombre de archivo y la ruta siempre deben formar parte de la clave, puedes incluir u omitir cualquier combinación de protocolo, host o cadena de consulta al personalizar la clave de caché. En Usar claves de caché se describe cómo personalizar las claves de caché.

Parte del URI Personalización URLs de ejemplo que tienen la misma clave de caché
Protocolo Omitir el protocolo de la clave de caché.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Omitir el host de la clave de caché.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Cadena de consulta

Omitir la cadena de consulta de la clave de caché.

Omitir o incluir selectivamente partes de la cadena de consulta.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Además de incluir u omitir toda la cadena de consulta, puede usar partes de la cadena de consulta mediante listas de inclusión y listas de exclusión.

Lista de inclusión de cadenas de consulta

Puede controlar de forma selectiva qué parámetros de cadena de consulta incorpora Cloud CDN en las claves de caché. Por ejemplo, si creas una lista de inclusión de user, entonceshttps://example.com/images/cat.jpg?user=user1&color=blue se crea una clave de caché https://example.com/images/cat.jpg?user=user1 que también coincide con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debe incluir la cadena de consulta, especificar una lista de inclusión no vacía y no especificar una lista de exclusión.

Lista de inclusión de cadenas de consulta para claves de caché de Cloud Storage

Incluir parámetros de consulta de URL en las claves de caché de los segmentos de Cloud Storage ayuda a admitir el cache busting. La invalidación de caché permite que un usuario recupere una versión nueva del archivo que se ha subido, aunque la versión anterior siga almacenada en caché de forma válida según el ajuste de TTL.

Puede usar una lista de inclusión con parámetros de cadena de consulta en la clave de caché que se usa para servir respuestas de un segmento de backend. Aunque Cloud Storage no sirve contenido diferente ni enruta en función de los parámetros de consulta, puedes incluir parámetros que te permitan invalidar la caché del contenido estático almacenado en segmentos de Cloud Storage.

Por ejemplo, puedes añadir un parámetro de consulta ?version=VERSION o ?hash=HASH que se base en el contenido subyacente. De esta forma, se limita la necesidad de invalidar el contenido de forma proactiva y se adapta a los flujos de trabajo de desarrollo web modernos, en los que los frameworks web y las URLs usan un hash del contenido para evitar que se sirvan objetos obsoletos en las implementaciones.

Como la inclusión de parámetros de consulta en la clave de caché es opcional, Cloud CDN no admite la exclusión de parámetros de consulta de una clave de caché en un backend de almacenamiento.

Lista de exclusión de cadenas de consulta

Puedes controlar de forma selectiva qué parámetros de cadena de consulta ignora Cloud CDN mediante una lista de exclusión. Por ejemplo, si crea una lista de exclusión de user, todos los parámetros de cadena de consulta excepto user se usarán en la clave de caché.

Si la lista de exclusión está configurada y la entrada es https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN crea una clave de caché https://example.com/images/cat.jpg?color=blue que también coincide con https://example.com/images/cat.jpg?user=user2&color=blue, pero no con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debe incluir la cadena de consulta, especificar una lista de exclusión no vacía y no especificar una lista de inclusión.

Orden de los parámetros de consulta

La clave de caché generada no depende del orden de los parámetros de consulta.

Por ejemplo, los siguientes parámetros de consulta generan la misma clave de caché:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Configuración de encabezados HTTP y cookies HTTP

Puede mejorar las tasas de aciertos de caché y la descarga de origen con los siguientes ajustes de configuración de la clave de caché:

  • En el caso de los servicios de backend y los contenedores: usa encabezados HTTP como parte de las claves de caché. Para ello, incluye encabezados con nombre en la configuración de la clave de caché.
  • Solo para servicios de backend: usa cookies HTTP con nombre como claves de caché, como para pruebas A/B (multivariante), lanzamientos Canary y situaciones similares.

Las solicitudes de caché que incluyen encabezados HTTP o cookies HTTP adicionales en la solicitud se almacenan en caché en la tercera solicitud en una ubicación de caché para esa clave de caché. De esta forma, se reduce el impacto de los valores de encabezado o de cookie de alta cardinalidad en las tasas de desalojo de la caché. En circunstancias normales y con un tráfico de usuarios normal, esto no debería notarse y ayuda a que el contenido popular permanezca en la caché.

Incluir encabezados de solicitud

Para almacenar en caché variaciones adicionales de una respuesta, puede incluir encabezados de solicitud adicionales en la clave de caché.

Algunas encabezados no se permiten en las claves de caché porque suelen tener una cardinalidad muy alta. En la mayoría de los casos, los valores de estos encabezados son únicos por usuario (Cookie y Authorization) o tienen miles de valores probables (Referer, User-Agent y Accept). Por ejemplo, el encabezado User-Agent puede tener más de 5000 valores únicos debido a la gran variedad de navegadores, dispositivos de usuario y sistemas operativos. Estos tipos de encabezados tendrían un impacto negativo grave en las tasas de aciertos de caché.

Solo se aceptan nombres de campos de encabezado HTTP válidos según el RFC 7230. Los nombres de los campos de encabezado no distinguen entre mayúsculas y minúsculas, y no se permiten duplicados.

También puede configurar su servidor de origen para que incluya encabezados de solicitud de clave de caché configurados en la respuesta Vary. No es obligatorio para Cloud CDN, pero puede ser útil para las cachés de nivel inferior. Para obtener más información, consulta Variar encabezados.

Cloud CDN no permite que se incluyan los siguientes encabezados en la lista de encabezados:

  • Accept
  • Accept-Encoding
  • Authority, ya que se controla mediante la configuración (cdnPolicy.includeHost)
  • Authorization, normalmente por usuario, como en los tokens de OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, a menudo por cliente o por proxy
  • From
  • Host, ya que se controla mediante la configuración (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since o If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (o Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken y X-CSRF-Token, tal como los usan Django y Ruby on Rails
  • X-Forwarded-For, a menudo por cliente o por proxy
  • X-User-IP
  • Cualquier encabezado que empiece por lo siguiente:
    • Access-Control-, como Access-Control-Request-Headers y Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Usar variables personalizadas con encabezados de solicitud

Las claves de caché son útiles cuando necesitas servir contenido de forma diferente en función del dispositivo y la ubicación de cada usuario. Por ejemplo, puedes habilitar un sitio web adaptable para que muestre las imágenes adecuadas a los usuarios que estén viendo contenido en función del tipo de dispositivo o definir un idioma predeterminado útil en función de su ubicación. Puedes definir claves de caché mediante encabezados de solicitud personalizados y variables personalizadas.

Para usar variables personalizadas con encabezados de solicitud, siga estos pasos:

  1. Define un encabezado de solicitud personalizado para tu servicio de backend. Incluya una o varias variables para el valor del encabezado de solicitud personalizado.
  2. Actualiza la clave de caché para usar el encabezado de solicitud personalizado.

En Cloud CDN, solo puede usar las siguientes variables al definir encabezados que sean tanto encabezados de solicitud personalizados como encabezados de clave de caché:

  • device_request_type
  • user_agent_family
  • client_region
  • client_region_subdivision

Cloud CDN limita las variables para mantener el rendimiento de la caché. Es similar a los límites de los encabezados que se pueden usar como claves de caché.

Por ejemplo, si especificara X-Lat-Long:{client_city_lat_long} como encabezado de solicitud personalizado y, a continuación, añadiera X-Lat-Long a su conjunto de encabezados de clave de caché, Cloud CDN intentaría almacenar en caché una copia de la respuesta para cada valor de client_city_lat_long. Esto provocaría un uso excesivo de la caché, un vaciado innecesario del contenido y una menor oportunidad de devolver aciertos de caché.

Por estos motivos, las variables con una cardinalidad alta no se incluyen en la lista de variables que se usan para definir encabezados de solicitud personalizados y, posteriormente, claves de caché.

Mismos encabezados con valores diferentes

Supongamos que el usuario envía varios encabezados con el mismo nombre y con valores diferentes. Por ejemplo:

My-Header: Value1
My-Header: Value2

En este caso, Cloud CDN modifica la solicitud asumiendo que el encabezado debe seguir la convención estándar que permite que algunos encabezados tengan varios valores. Cloud CDN las combina en una lista separada por comas para enviarlas al backend, por lo que es como si el cliente hubiera enviado lo siguiente:

My-Header: Value1, Value2

Incluir cookies con nombre

Una cookie HTTP es un emparejamiento name=value y una solicitud puede incluir varias cookies HTTP, ya sea separadas por un punto y coma en la misma línea o como encabezados de solicitud Cookie independientes con una cookie por encabezado.

Puedes proporcionar una lista de hasta cinco nombres de cookies.

Los agentes de usuario (como los navegadores web) suelen limitar a 4 KB el número de cookies almacenadas por dominio. Asegúrate de no enviar demasiadas cookies (o cookies demasiado grandes), ya que es posible que el agente de usuario no envíe todas las cookies en una solicitud. Esto puede influir en si un usuario recibe una respuesta específica almacenada en caché.

Si sirve su contenido estático desde un nombre de host diferente al que usa para emitir cookies, asegúrese de que el atributo Domain de la cookie (y el atributo Path) permita que la cookie se envíe junto con las solicitudes de contenido estático.

Si una solicitud incluye varias instancias del mismo nombre de cookie, solo se tiene en cuenta la primera.

Directivas de control de caché

Las directivas de control de caché HTTP afectan al comportamiento de Cloud CDN, tal como se indica en la siguiente tabla.

N/A significa que una directiva no se aplica a una solicitud o respuesta.

Directive Solicitud Respuesta
no-store Si se incluye en una solicitud, Cloud CDN la respeta y no almacena la respuesta en la caché.

No se almacena en caché una respuesta con no-store.

Esta opción se puede anular en cada backend con el modo de caché FORCE_CACHE_ALL.

no-cache Se ignora la directiva de solicitud no-cache para evitar que los clientes inicien o fuercen la revalidación al origen.

Se almacena en caché una respuesta con no-cache, pero debe volver a validarse con el origen antes de servirse.

Esta opción se puede anular en cada backend con el modo de caché FORCE_CACHE_ALL.

public N/A

Esta directiva no es obligatoria para que se pueda almacenar en caché, pero es una práctica recomendada incluirla en el contenido que deben almacenar en caché los proxies.

private N/A

Cloud CDN no almacena en caché las respuestas con la directiva private, aunque se consideren almacenables en caché. Los clientes (como los navegadores) pueden seguir almacenando en caché el resultado.

Esta opción se puede anular en cada backend con el modo de caché FORCE_CACHE_ALL. Usa no-store para evitar que se almacenen en caché todas las respuestas.

max-age=SECONDS Se ignora la directiva de solicitud max-age. Se devuelve una respuesta almacenada en caché como si este encabezado no se hubiera incluido en la solicitud. Una respuesta con la directiva max-age se almacena en caché hasta el SECONDS definido.
s-maxage=SECONDS N/A

Una respuesta con la directiva s-maxage se almacena en caché hasta el SECONDS definido.

Si están presentes max-age y s-maxage, Cloud CDN usa s‑maxage.

Las respuestas con esta directiva no se sirven obsoletas.

s-max-age (dos guiones) no es válido para el almacenamiento en caché.

min-fresh=SECONDS Se ignora la directiva de solicitud min-fresh. Se devuelve una respuesta almacenada en caché como si este encabezado no se hubiera incluido en la solicitud. N/A
max-stale=SECONDS

La directiva de solicitud max-stale determina la obsolescencia máxima (en segundos) que el cliente está dispuesto a aceptar.

La CDN de Cloud respeta este valor y devuelve una respuesta almacenada en caché obsoleta solo si la obsolescencia de la respuesta es inferior a la directiva max-stale. De lo contrario, se vuelve a validar antes de servir la solicitud.

 N/A
stale-while-revalidate=SECONDS N/A

Se sirve una respuesta con stale-while-revalidate a un cliente durante un máximo de SECONDS mientras se lleva a cabo la revalidación de forma asíncrona.

Este comportamiento se puede habilitar en todas las respuestas si se define cdnPolicy.serveWhileStale en el backend.

stale-if-error=SECONDS Se ignora la directiva de solicitud stale-if-error. Se devuelve una respuesta almacenada en caché como si este encabezado no se hubiera incluido en la solicitud.

Esta cabecera de respuesta no tiene ningún efecto.

must-revalidate N/A

Una respuesta con must-revalidate se vuelve a validar con el servidor de origen después de que caduque.

Las respuestas con esta directiva no se sirven obsoletas.

proxy-revalidate

Una respuesta con proxy-revalidate se vuelve a validar con el servidor de origen después de que caduque.

Las respuestas con esta directiva no se sirven obsoletas.

immutable N/A Sin efectos. Se envía al cliente en la respuesta.
no-transform N/A Cloud CDN no aplica ninguna transformación.
only-if-cached Se ignora la directiva de solicitud only-if-cached. Se devuelve una respuesta almacenada en caché como si este encabezado no se hubiera incluido en la solicitud. N/A

Siempre que sea posible, Cloud CDN se esfuerza por cumplir el RFC (RFC 7234 de HTTP), pero prioriza la optimización de la descarga de la caché y la minimización del impacto que pueden tener los clientes en la tasa de aciertos y en la carga general del origen.

En las respuestas que usan el encabezado Expires de HTTP/1.1:

  • El valor del encabezado Expires debe ser una fecha HTTP válida, tal como se define en RFC 7231.
  • Si se indica una fecha anterior, una fecha no válida o el valor 0, significa que el contenido ya ha caducado y debe volver a validarse.
  • Si hay un encabezado Cache-Control en la respuesta, Cloud CDN ignora el encabezado Expires.

La presencia de un encabezado Expires válido y futuro en la respuesta permite que esta se almacene en caché y no requiere que se especifiquen otras directivas de caché.

El encabezado Pragma de HTTP/1.0, si está presente en una respuesta, se ignora y se envía tal cual al cliente. Las solicitudes de clientes con este encabezado se envían al origen y no influyen en la forma en que Cloud CDN sirve una respuesta.

Vary encabezados

La cabecera Vary indica que la respuesta varía en función de las cabeceras de solicitud del cliente. Además del URI de solicitud, Cloud CDN respeta los encabezados Vary que los servidores de origen incluyen en las respuestas. Por ejemplo, si una respuesta especifica Vary: Accept, Cloud CDN usa una entrada de caché para las solicitudes que especifican Accept: image/webp,image/*,*/*;q=0.8 y otra para las solicitudes que especifican Accept: */*.

En la tabla de la sección Contenido no almacenable en caché se enumeran los encabezados Vary que permiten almacenar contenido en caché. Otros valores de encabezado Vary impiden que se almacene contenido en caché.

El modo de caché FORCE_CACHE_ALL no anula este comportamiento. Los encabezados Vary son importantes para evitar el envenenamiento de la caché entre varias respuestas posibles del servidor de origen. Sería peligroso que FORCE_CACHE_ALL provocara que esas respuestas se almacenaran en caché.

Las cabeceras Vary se usan a veces cuando se sirve contenido comprimido. Cloud CDN no comprime ni descomprime las respuestas (a menos que se haya habilitado la compresión dinámica), pero puede servir respuestas que el servidor de origen haya comprimido. Si tu servidor de origen elige si sirve contenido comprimido o sin comprimir en función del valor del encabezado de solicitud Accept-Encoding, asegúrate de que la respuesta especifique Vary: Accept-Encoding.

Cuando se usan cabeceras HTTP en la clave de caché, Cloud CDN almacena en caché varias copias de la respuesta en función de los valores de las cabeceras de solicitud especificadas, de forma similar a la compatibilidad con Vary, pero sin que el servidor de origen tenga que especificar explícitamente ninguna cabecera de respuesta Vary. Si el origen especifica los encabezados de clave de caché en la respuesta Vary, Cloud CDN trata la respuesta correctamente, como si los encabezados no se hubieran mencionado en la respuesta Vary.

Tiempos de vencimiento y solicitudes de validación

El tiempo de caducidad de una entrada de caché define el tiempo durante el que esta sigue siendo válida. El valor proporcionado por s-maxage (max-age o expires) permite volver a validar automáticamente el contenido almacenado en caché obsoleto generado por los usuarios.

Cuando Cloud CDN recibe una solicitud, busca la entrada de caché correspondiente y comprueba su antigüedad. Si la entrada de caché existe y está lo suficientemente actualizada, la respuesta se puede proporcionar desde la caché. Si ha pasado el tiempo de vencimiento, Cloud CDN intenta volver a validar la entrada de caché poniéndose en contacto con uno de tus back-ends. Esto se hace antes de servir la respuesta, a menos que habilites serve-while-stale, en cuyo caso la revalidación se realiza de forma asíncrona.

En algunos modos de caché, puedes definir valores de TTL. Para obtener más información, consulta Usar la configuración de TTL y las anulaciones.

El modo de caché afecta a la forma en que se determina la actualización.

Modo de caché Comportamiento de validación
CACHE_ALL_STATIC Los encabezados de origen (Cache-Control: s-maxage, Cache-Control: max-age o Expires) se consultan para determinar la actualización. En el caso del contenido estático, si no hay encabezados de origen, la default_ttl configurada determina la actualización. Cuando el contenido estático tiene más de default_ttl, Cloud CDN lo vuelve a validar.
USE_ORIGIN_HEADERS Cada entrada de caché de Cloud CDN tiene un tiempo de vencimiento definido por los encabezados Cache-Control: s-maxage, Cache-Control: max-age o Expires de acuerdo con RFC 7234.
FORCE_CACHE_ALL En lugar de los encabezados de origen, la default_ttl configurada determina la actualización. Cuando el contenido tiene más de default_ttl, Cloud CDN lo vuelve a validar.

Si hay más de uno, Cache-Control: s-maxage tiene prioridad sobre Cache-Control: max-age y Cache-Control: max-age tiene prioridad sobre Expires.

De forma predeterminada, cuando el valor del tiempo de caducidad supera los 30 días (2.592.000 segundos), Cloud CDN trata el valor de caducidad como si fuera de 2.592.000 segundos. Los clientes de nivel inferior seguirán viendo los valores correctos de max-age y s-maxage, aunque superen los 30 días.

Desalojo

No se garantiza que una entrada de la caché permanezca en ella hasta que caduque, ya que las entradas poco populares se pueden eliminar antes de que caduquen en cualquier momento para dejar espacio a contenido nuevo. Como límite superior, las entradas de caché a las que no se accede durante 30 días se eliminan automáticamente.

Para obtener más información, consulta Desalojo y caducidad.

Usar solicitudes condicionales para la validación

La CDN de Cloud puede intentar usar la información de los encabezados de respuesta almacenados en caché para validar la entrada de caché con el backend. Esto ocurre cuando se cumplen estas dos condiciones:

  • La respuesta almacenada en caché anteriormente tiene un encabezado Last-Modified o ETag.
  • La solicitud del cliente es una solicitud GET que no contiene los encabezados If-Modified-Since ni If-None-Match.

Cloud CDN realiza esta validación de forma ligeramente diferente en función de si la respuesta se ha almacenado en caché mediante solicitudes de intervalo de bytes:

  • Si la respuesta se ha almacenado en caché mediante solicitudes de intervalo de bytes, Cloud CDN inicia una solicitud de validación independiente que incluye los encabezados If-Modified-Since y If-None-Match.
  • De lo contrario, Cloud CDN añade los encabezados If-Modified-Since y If-None-Match a la solicitud del cliente y reenvía la solicitud modificada al backend.

Si la copia almacenada en caché sigue estando actualizada, el backend puede validar la entrada de caché enviando una respuesta 304 Not Modified. En este caso, el backend solo envía los encabezados de respuesta, no el cuerpo de la respuesta. La CDN de Cloud inserta los nuevos encabezados de respuesta en la caché, actualiza el tiempo de vencimiento y envía los nuevos encabezados de respuesta y el cuerpo de respuesta almacenado en caché al cliente.

Si la respuesta almacenada en caché anteriormente no tiene un encabezado Last-Modified o ETag, Cloud CDN ignora la entrada de caché caducada y reenvía la solicitud del cliente al backend sin modificarla.

Compatibilidad con solicitudes de intervalo de bytes

Una respuesta que cumpla los siguientes criterios indica que el servidor de origen admite solicitudes de intervalo de bytes:

  • Código de estado: 200 OK o 206 Partial Content
  • Encabezado: Accept-Ranges: bytes
  • Encabezado: Content-Length. En el caso de una respuesta 206 Partial Content, un valor Content-Range que indica la longitud completa del objeto de origen. Por ejemplo, Content-length: 0-100/999 se puede almacenar en caché, mientras que Content-length: 0-100/* no.
  • Encabezado: Last-Modified y ETag con un validador sólido.

Cloud Storage admite solicitudes de intervalos de bytes para la mayoría de los objetos. Sin embargo, Cloud Storage no admite solicitudes de intervalos de bytes para objetos con metadatos Content-Encoding: gzip, a menos que la solicitud del cliente incluya un encabezado Accept- Encoding: gzip. Si tienes objetos de Cloud Storage de más de 10 MB, asegúrate de que no tengan metadatos Content-Encoding: gzip. Para obtener información sobre cómo editar los metadatos de un objeto, consulta Ver y editar metadatos de objetos.

El software de servidor web más popular también admite solicitudes de intervalo de bytes. Consulta la documentación de tu servidor web para obtener información sobre cómo habilitar la compatibilidad. Para obtener más información sobre las solicitudes de intervalo de bytes, consulta la especificación HTTP.

Cuando un servidor de origen admite solicitudes de intervalo de bytes, una caché de Cloud CDN rechaza almacenar una respuesta que, de lo contrario, se podría almacenar en caché la primera vez que se solicita si se cumple alguna de las siguientes condiciones:

  • El cuerpo de la respuesta está incompleto porque el cliente solo ha solicitado una parte del contenido.
  • El cuerpo de la respuesta es superior a 1 MB (1.048.576 bytes).

Cuando esto ocurre y la respuesta cumpliría los requisitos de almacenamiento en caché normales, la caché registra que el servidor de origen admite solicitudes de intervalo de bytes para esa clave de caché y reenvía la respuesta del servidor de origen al cliente.

Si no hay resultados en caché, la caché comprueba si el servidor de origen admite solicitudes de intervalo de bytes. Si se sabe que las solicitudes de intervalo de bytes se admiten en la clave de caché, la caché no reenvía la solicitud del cliente al balanceador de carga de aplicación externo. En su lugar, la caché inicia sus propias solicitudes de relleno de caché de intervalo de bytes para las partes que faltan del contenido.

El servidor de origen devuelve una respuesta 206 Partial Content cuando Cloud CDN inicia su propia solicitud de relleno de caché de intervalo de bytes. Para que se tenga en cuenta una respuesta 206 Partial Content al almacenar en caché, debe incluir un encabezado Content-Range con una directiva complete-length que no incluya asteriscos. Por ejemplo, 0-100/999. A continuación, Cloud CDN almacena en caché esa respuesta 206 Partial Content y la usa para responder a futuras solicitudes de clientes de ese contenido.

Una caché almacena una respuesta 206 Partial Content solo cuando se recibe en respuesta a una solicitud de intervalo de bytes que ha iniciado la caché. Como una caché no inicia una solicitud de intervalo de bytes a menos que haya registrado previamente que el servidor de origen admite solicitudes de intervalo de bytes para esa clave de caché, una caché determinada no almacena contenido de más de 1 MB hasta la segunda vez que se accede a ese contenido.

Debido a su naturaleza distribuida, Cloud CDN puede obtener el último fragmento del origen más de una vez por ubicación. Esto solo afecta a las primeras solicitudes por clave de caché.

Solicitar la combinación de solicitudes

La compresión de solicitudes (también llamada fusión) comprime de forma activa varias solicitudes de llenado de caché iniciadas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo de periferia. De esta forma, se puede reducir activamente la carga del origen. Además, se aplica tanto a las solicitudes de elementos (respuestas obtenidas directamente) como a las solicitudes de fragmentos, en las que Cloud CDN usa solicitudes Range para obtener objetos más grandes de forma más eficiente.

La función de contraer solicitudes está habilitada de forma predeterminada.

Las solicitudes combinadas se comportan de la siguiente manera:

  • Las solicitudes combinadas registran tanto la solicitud visible para el cliente como la solicitud de relleno de caché (combinada).
  • El líder de la sesión contraída se usa para hacer la solicitud de relleno del origen.
  • Los atributos de solicitud que no forman parte de la clave de caché, como los encabezados User-Agent o Accept-Encoding, solo reflejan el líder de la sesión contraída.
  • Las solicitudes que no tienen la misma clave de caché no se pueden contraer.

En el siguiente diagrama se muestra cómo se combinan las solicitudes:

Cloud CDN con la función de combinar solicitudes habilitada.
Cloud CDN con la función de combinar solicitudes habilitada (haz clic para ampliar).

En cambio, si la combinación de solicitudes está inhabilitada o si se trata de solicitudes que no se pueden combinar, el número de solicitudes de origen y respuestas puede ser igual al número de clientes que intentan obtener un objeto que no está en la caché.

Cloud CDN sin la función de combinar solicitudes habilitada.
Cloud CDN con la función de combinar solicitudes inhabilitada (haga clic para ampliar).

En todos los tipos de solicitudes, la función de contraer está habilitada de forma predeterminada. En el caso de los tipos de solicitudes de artículos, puedes inhabilitar la función de contraer. Recomendamos inhabilitar la compresión de solicitudes de elementos en situaciones en las que la latencia es muy importante, como la publicación de anuncios, en las que la carga del origen no es un factor a tener en cuenta.

En la siguiente tabla se resumen el comportamiento predeterminado y la configurabilidad de los diferentes tipos de solicitudes.

Tipo de solicitud Comportamiento predeterminado Se pueden configurar. Ventajas de contraer
Solicitudes de fragmentos Habilitado No Puede reducir significativamente el ancho de banda del origen
Solicitudes de artículos Habilitado Sí Puede reducir el volumen de solicitudes de origen

Para inhabilitar la fusión de solicitudes de elementos mediante Google Cloud CLI en un segmento de backend que haga referencia a un segmento de Cloud Storage, sigue estos pasos:

gcloud

Usa el comando gcloud compute backend-services o backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Para habilitar la fusión de solicitudes de elementos en un segmento de backend mediante la CLI de Google Cloud, sigue estos pasos:

gcloud

Usa el comando gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Para habilitar la fusión de solicitudes de elementos mediante la CLI de Google Cloud en un servicio de backend, incluidos los grupos de VMs y los backends externos, sigue estos pasos:

gcloud

Usa el comando gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Solicitudes iniciadas por Cloud CDN

Si tu servidor de origen admite solicitudes de intervalo de bytes, Cloud CDN puede enviar varias solicitudes a tu servidor de origen en respuesta a una sola solicitud de cliente. Cloud CDN puede iniciar dos tipos de solicitudes: de validación y de intervalo de bytes.

Si la respuesta que indicaba que tu servidor de origen admitía solicitudes de intervalo de bytes para una clave de caché concreta ha caducado, Cloud CDN inicia una solicitud de validación para confirmar que el contenido no ha cambiado y que tu servidor de origen sigue admitiendo solicitudes de intervalo para el contenido. Si tu servidor de origen responde con una respuesta 304 Not Modified, Cloud CDN procederá a servir el contenido mediante rangos de bytes. De lo contrario, Cloud CDN reenvía la respuesta de tu servidor de origen al cliente. Puedes controlar los tiempos de vencimiento mediante los Cache-Control y Expiresencabezados de respuesta.

Si no se encuentra en la caché, Cloud CDN inicia solicitudes de llenado de caché para un conjunto de intervalos de bytes que se superponen a la solicitud del cliente. Si algunos intervalos del contenido solicitado por el cliente están en la caché, Cloud CDN sirve lo que puede desde la caché y envía solicitudes de intervalo de bytes solo para los intervalos que faltan a tu servidor de origen.

Cada solicitud de intervalo de bytes iniciada por Cloud CDN especifica un intervalo que comienza en un desplazamiento que es un múltiplo de 2.097.136 bytes. Con la posible excepción del intervalo final, cada intervalo también es de 2.097.136 bytes. Si el contenido no es un múltiplo de ese tamaño, el intervalo final será menor. El tamaño y los desplazamientos utilizados en las solicitudes de intervalo de bytes pueden cambiar en el futuro.

Por ejemplo, supongamos que un cliente solicita los bytes del 1.000.000 al 3.999.999 de contenido que no está en la caché. En este ejemplo, Cloud CDN podría iniciar dos solicitudes GET: una para los primeros 2.097.136 bytes del contenido y otra para los segundos 2.097.136 bytes. Esto da como resultado 4.194.272 bytes de relleno de caché, aunque el cliente solo haya solicitado 3.000.000 bytes.

Cuando usas un segmento de Cloud Storage como origen, cada solicitud GET se factura como una operación de clase B independiente. Se te cobrarán todas las solicitudes GET procesadas por Cloud Storage, incluidas las solicitudes iniciadas por Cloud CDN. Cuando una respuesta se sirve por completo desde una caché de Cloud CDN, no se envía ninguna solicitud GET a Cloud Storage y no se te cobra ninguna operación de Cloud Storage.

Cuando Cloud CDN inicia una solicitud de validación o una solicitud de intervalo de bytes, no incluye encabezados específicos del cliente, como Cookie o User-Agent.

En el campo Cloud Logging httpRequest.userAgent (Registro de Cloud), Cloud-CDN-Google significa que Cloud CDN ha iniciado la solicitud.

Omitir la caché

La omisión de la caché permite que las solicitudes que contengan encabezados de solicitud específicos omitan la caché, aunque el contenido se haya almacenado en caché anteriormente.

En esta sección se proporciona información sobre cómo saltarse la caché con encabezados HTTP, como Pragma y Authorization. Esta función es útil cuando quieres asegurarte de que tus usuarios o clientes siempre tengan el contenido más reciente obtenido directamente del servidor de origen. Puede que quieras hacerlo para probar, configurar directorios de staging o scripts.

Si coincide un encabezado especificado, se omite la caché para todos los ajustes del modo de caché, incluso FORCE_CACHE_ALL. Si se omite la caché, se producirá un gran número de errores de caché si los encabezados especificados son comunes a muchas solicitudes.

Antes de empezar

  • Asegúrate de que Cloud CDN esté habilitado. Para obtener instrucciones, consulta el artículo Usar Cloud CDN.

  • Si es necesario, actualiza a la versión más reciente de la CLI de Google Cloud:

    gcloud components update

Configurar la omisión de caché

Puedes especificar hasta cinco nombres de encabezado HTTP. En estos valores, el sistema no distingue entre mayúsculas y minúsculas. El nombre del encabezado debe ser un token de campo de encabezado HTTP válido. Un nombre de encabezado no puede aparecer más de una vez en la lista de encabezados añadidos. Para consultar las reglas sobre los nombres de encabezado válidos, consulta Cómo funcionan los encabezados personalizados.

Consola

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a la página Balanceo de carga

  2. Haga clic en el nombre de su balanceador de carga de aplicaciones externo.
  3. Haz clic en Editar .
  4. En Configuración de backend, selecciona un backend y haz clic en Editar .
  5. Asegúrate de que la opción Habilitar Cloud CDN esté seleccionada.
  6. En la parte inferior de la ventana, haz clic en Configuraciones avanzadas.
  7. En Omitir la caché en el encabezado de solicitud, haga clic en Añadir encabezado.
  8. Escribe un nombre de encabezado, como Pragma o Authorization.
  9. Haz clic en Actualizar.
  10. Vuelve a hacer clic en Actualizar.

gcloud

En el caso de los segmentos de backend, usa el comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con la marca --bypass-cache-on-request-headers.

En el caso de los servicios de backend, usa el comando gcloud compute backend-services create o gcloud compute backend-services update con la marca --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Por ejemplo:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

API

En el caso de los backend buckets, usa la llamada a la API Method: backendBuckets.insert, Method: backendBuckets.update o Method: backendBuckets.patch.

En el caso de los servicios de backend, usa las llamadas a las APIs Method: backendServices.insert, Method: backendServices.update o Method: backendServices.patch.

Por ejemplo:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Añade el siguiente fragmento al cuerpo de la solicitud JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Inhabilitar la omisión de la caché

gcloud

En el caso de los segmentos de backend, usa el comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con la marca --no-bypass-cache-on-request-headers.

En el caso de los servicios de backend, usa el comando gcloud compute backend-services create o gcloud compute backend-services update con la marca --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

API

En el caso de los segmentos de backend, usa la llamada a la API Method: backendBuckets.insert o Method: backendBuckets.update.

En el caso de los servicios de backend, usa la llamada a la API Method: backendServices.insert o Method: backendServices.update.

Usa una de las siguientes llamadas a la API:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Añade el siguiente fragmento al cuerpo de la solicitud JSON:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Siguientes pasos