Vista geral da colocação em cache

Uma resposta armazenável em cache é uma resposta HTTP que a RFC do Google Cloud pode armazenar e obter rapidamente, o que permite tempos de carregamento mais rápidos. Nem todas as respostas HTTP são colocáveis em cache.

Modos de cache

Com os modos de cache, pode controlar os fatores que determinam se a RFC armazena em cache o seu conteúdo.

A RFC de nuvem oferece três modos de cache, que definem como as respostas são colocadas em cache, se a RFC de nuvem respeita as diretivas de cache enviadas pela origem e como os TTLs de cache são aplicados.

Os modos de cache disponíveis são apresentados na tabela seguinte:

Modo de cache Comportamento
CACHE_ALL_STATIC Coloca automaticamente em cache as respostas bem-sucedidas com conteúdo estático que, de outra forma, não seria colocado em cache. As respostas de origem que definem diretivas de colocação em cache válidas também são colocadas em cache.

Este comportamento é o predefinido para back-ends ativados para a Cloud CDN criados através da Google Cloud CLI ou da API REST.
USE_ORIGIN_HEADERS Requer respostas de origem bem-sucedidas para definir diretivas de cache válidas e cabeçalhos de cache válidos. As respostas bem-sucedidas sem estas diretivas são encaminhadas a partir da origem.
FORCE_CACHE_ALL Coloca em cache incondicionalmente as respostas bem-sucedidas, substituindo quaisquer diretivas de cache definidas pela origem. Este modo não é adequado se o back-end servir conteúdo privado por utilizador (identificável pelo utilizador), como HTML dinâmico ou respostas da API.

As respostas de erro podem ser colocadas em cache, mesmo na ausência de diretivas de cache válidas.

Antes de definir o modo de cache como FORCE_CACHE_ALL, considere os seguintes comportamentos:

  • Para URLs assinados ou cookies assinados, FORCE_CACHE_ALL substitui a duração máxima especificada através da definição Duração máxima da entrada na cache na Google Cloud consola ou na opção gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL altera o tempo de vida (TTL) de qualquer conteúdo armazenado em cache anteriormente. Esta alteração pode fazer com que algumas entradas que eram consideradas atualizadas (devido a terem TTLs mais longos dos cabeçalhos de origem) sejam consideradas desatualizadas e pode fazer com que algumas entradas que eram consideradas desatualizadas sejam consideradas atualizadas.

  • FORCE_CACHE_ALL substitui as diretivas de cache (Cache-Control e Expires), mas não substitui outros cabeçalhos de resposta de origem. Em particular, um cabeçalho Vary pode suprimir o armazenamento em cache, mesmo que o modo de cache seja FORCE_CACHE_ALL. Para mais informações, consulte o artigo Cabeçalhos Vary.

Para ver instruções de configuração, consulte o artigo Definir o modo de cache.

Conteúdo estático

O conteúdo estático é conteúdo que é sempre o mesmo, mesmo quando acedido por diferentes utilizadores. Normalmente, o CSS que usa para aplicar estilos ao seu site, o JavaScript para fornecer interatividade, o conteúdo de vídeo e de imagem não se alteram para cada utilizador para um determinado URL (chave de cache) e, por isso, beneficiam da colocação em cache na rede de limite global da Cloud CDN.

Quando define o modo de cache como CACHE_ALL_STATIC e uma resposta não tem diretivas de colocação em cache explícitas nos cabeçalhos Cache-Control ou Expires, o Cloud CDN coloca automaticamente essa resposta em cache para o seguinte:

  • Recursos Web, incluindo CSS (text/css), JavaScript (application/javascript) e todas as carateres Web, incluindo WOFF2 (font/woff2)
  • Imagens, incluindo JPEG (image/jpg) e PNG (image/png)
  • Vídeos, incluindo H.264, H.265 e MP4 (video/mp4)
  • Ficheiros de áudio, incluindo MP3 (audio/mpeg) e MP4 (audio/mp4)
  • Documentos formatados, incluindo PDF (application/pdf)

A tabela seguinte apresenta um resumo.

Categoria Tipos MIME
Recursos Web text/css text/ecmascript text/javascript application/javascript
Tipos de letra Qualquer Content-Type que corresponda a font/*
Imagens Qualquer Content-Type que corresponda a image/*
Vídeos Qualquer Content-Type que corresponda a video/*
Áudio Qualquer Content-Type que corresponda a audio/*
Tipos de documentos formatados application/pdf e application/postscript

A RFC na nuvem inspeciona o cabeçalho da resposta HTTP, que reflete o tipo MIME do conteúdo publicado.Content-Type

Tenha em conta o seguinte:

  • O software do servidor Web da sua origem tem de definir o Content-Type para cada resposta. Muitos servidores Web definem automaticamente o cabeçalho Content-Type, incluindo o NGINX, o Varnish e o Apache.

  • O Cloud Storage define o cabeçalho Content-Type automaticamente quando usa a Google Cloud consola ou a CLI do Google Cloud para carregar conteúdo.

  • O Cloud Storage fornece sempre um cabeçalho Cache-Control ao Cloud CDN. Se não for escolhido explicitamente nenhum valor, envia um valor predefinido. Como resultado, todas as respostas bem-sucedidas do Cloud Storage são colocadas em cache de acordo com os valores predefinidos do Cloud Storage, a menos que ajuste explicitamente os metadados de controlo da cache para objetos no Cloud Storage ou use o modo FORCE_CACHE_ALL para substituir os valores enviados pelo Cloud Storage.

  • Se quiser colocar em cache os tipos de conteúdo text/html e application/json, tem de definir cabeçalhos explícitos Cache-Control na resposta, tendo cuidado para não colocar acidentalmente em cache os dados de um utilizador e disponibilizá-los a todos os utilizadores.

Se uma resposta for armazenável em cache com base no respetivo tipo MIME, mas tiver um cabeçalho de resposta Cache-Control de private ou no-store, ou um cabeçalho Set-Cookie , não é armazenada em cache. Para saber mais, consulte as regras de capacidade de colocação em cache.

Outros tipos de conteúdo, como HTML (text/html) e JSON (application/json), não são colocados em cache por predefinição para respostas bem-sucedidas. Estes tipos de respostas são normalmente dinâmicos (por utilizador). Os exemplos incluem carrinhos de compras, páginas de produtos com personalização do utilizador e respostas de API autenticadas. No entanto, se a colocação em cache negativa estiver ativada, pode continuar a fazer com que sejam colocadas em cache para determinados códigos de estado.

A CDN da nuvem não usa extensões de ficheiros no caminho do URL para determinar se uma resposta é armazenável em cache, porque muitas respostas armazenáveis em cache válidas não se refletem nos URLs.

Conteúdo armazenável em cache

A RFC de multimédia na nuvem coloca em cache as respostas que cumprem todos os requisitos nesta secção. Alguns destes requisitos são especificados pela RFC 7234 e outros são específicos da RFC.

A CDN na nuvem pode alterar periodicamente o conjunto exato de condições sob as quais armazena conteúdo em cache. Se quiser impedir explicitamente que a CDN da nuvem armazene em cache o seu conteúdo, siga as diretrizes na RFC 7234 para determinar como especificar uma resposta garantidamente não armazenável em cache. Consulte também a secção Conteúdo não armazenável em cache com base nos cabeçalhos de origem.

O Cloud CDN armazena as respostas na cache se todas as seguintes condições forem verdadeiras.

Atributo Requisito
Apresentado por Serviço de back-end, contentor de back-end ou um back-end externo com o Cloud CDN ativado
Em resposta a GET pedido
Código de estado

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 ou 501.
Atualidade

A resposta tem um cabeçalho Cache-Control com uma diretiva max-age ou s-maxage, ou um cabeçalho Expires com uma data/hora no futuro.

Para respostas memorizáveis em cache sem idade (por exemplo, com no-cache), a diretiva public tem de ser fornecida explicitamente.

Com o modo de cache CACHE_ALL_STATIC, se não estiverem presentes diretivas de atualização, uma resposta bem-sucedida com o tipo de conteúdo estático continua a ser elegível para colocação em cache.

Com o modo de cache FORCE_CACHE_ALL, qualquer resposta bem-sucedida é elegível para colocação em cache. Isto pode resultar na colocação em cache de conteúdo privado por utilizador. Só deve definir FORCE_CACHE_ALL em back-ends que não estejam a publicar conteúdo privado ou dinâmico, como contentores do Cloud Storage.

Se o armazenamento em cache negativo estiver ativado e o código de estado corresponder a um para o qual o armazenamento em cache negativo especifica um TTL, a resposta é elegível para o armazenamento em cache, mesmo sem diretivas de atualização explícitas.
Conteúdo

Para origens HTTP/1, a resposta tem de conter um cabeçalho Content-Length, Content-Range ou Transfer-Encoding: chunked válido.

Para origens que usam versões mais avançadas do protocolo HTTP (HTTP/2 e posteriormente), a resposta não precisa de ter esses cabeçalhos.
Tamanho Inferior ou igual ao tamanho máximo.

Para respostas com tamanhos entre 10 MiB e 100 GiB, consulte as restrições de capacidade de colocação em cache adicionais descritas nos pedidos de intervalo de bytes.

Para contentores de back-end do Cloud Storage, siga estas sugestões adicionais:

Por predefinição, quando um objeto é público e não especifica metadados, o Cloud Storage atribui um cabeçalho Cache-Control: public, max-age=3600 ao objeto.Cache-Control Pode definir valores diferentes através de metadados Cache-Control.

Para ver um exemplo que mostra como configurar um balanceador de carga de aplicações externo com um contentor de back-end, consulte o artigo Configurar o Cloud CDN com um contentor de back-end.

Tamanho máximo

A CDN da nuvem aplica um tamanho máximo a cada resposta. Qualquer resposta com um corpo superior ao tamanho máximo não é colocada em cache, mas é entregue ao cliente.

O tamanho máximo varia consoante o servidor de origem suportar pedidos de intervalo de bytes.

O servidor de origem suporta pedidos de intervalo de bytes O servidor de origem não suporta pedidos de intervalo de bytes
100 GiB (107 374 182 400 bytes) 10 MiB (10 485 760 bytes)

Quase todos os servidores Web modernos (incluindo NGINX, Apache e Varnish) suportam pedidos de intervalo de bytes.

Conteúdo não armazenável em cache com base nos cabeçalhos de origem

Existem verificações que bloqueiam o armazenamento em cache das respostas. A RFC de multimédia na nuvem pode alterar periodicamente o conjunto exato de condições em que coloca conteúdo em cache. Por isso, se quiser impedir explicitamente que a RFC de multimédia na nuvem coloque o seu conteúdo em cache, siga as diretrizes na RFC padrão (RFC 7234) para determinar como especificar uma resposta garantidamente não colocável em cache.

A RFC de multimédia na nuvem não armazena em cache uma resposta se não cumprir os requisitos para conteúdo armazenável em cache ou se qualquer uma das seguintes afirmações for verdadeira.

Atributo Requisito
Apresentado por Serviço de back-end ou back-end externo que não tem o Cloud CDN ativado
Cookie Tem um cabeçalho Set-Cookie
Vary cabeçalho Tem um valor diferente 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 ou um dos cabeçalhos configurados para fazer parte das definições da chave de cache.
Diretiva de resposta A resposta tem um cabeçalho Cache-Control com a diretiva no-store ou private (a menos que esteja a usar o modo de cache FORCE_CACHE_ALL, caso em que o cabeçalho Cache-Control é ignorado)
Diretiva de pedido O pedido tem uma diretiva Cache-Control: no-store
Pedir autorização O pedido tem um cabeçalho Authorization, a menos que seja substituído pelo Cache-Control da resposta.
Tamanho Superior ao tamanho máximo

Se Cache-Control: no-store ou private estiver presente, mas o conteúdo continuar a ser colocado em cache, isto deve-se a um dos seguintes motivos:

  • A assinatura de URLs está configurada.
  • O modo de cache do Cloud CDN está definido para forçar a colocação em cache de todas as respostas.

Impeça a colocação em cache

Para impedir que as informações privadas sejam colocadas em cache nas caches do Cloud CDN, faça o seguinte:

  1. Certifique-se de que o modo de cache da RFC na nuvem não está definido para o modo FORCE_CACHE_ALL, que coloca em cache incondicionalmente todas as respostas bem-sucedidas.
  2. Inclua um cabeçalho Cache-Control: private nas respostas que não devem ser armazenadas em caches da CDN na nuvem ou um cabeçalho Cache-Control: no-store nas respostas que não devem ser armazenadas em nenhuma cache, mesmo na cache de um navegador de Internet.
  3. Não assine URLs que forneçam acesso a informações privadas. Quando o conteúdo é acedido através de um URL assinado, é potencialmente elegível para colocação em cache, independentemente de quaisquer diretivas Cache-Control na resposta.
  4. Para pedidos de origem (preenchimento da cache) que incluem o cabeçalho de pedido Authorization, a RFC na nuvem apenas armazena em cache as respostas que incluem as diretivas de controlo da cache public, must-revalidate ou s-maxage quando o modo de cache está definido como USE_ORIGIN_HEADERS ou CACHE_ALL_STATIC. Isto evita o armazenamento em cache acidental de conteúdo por utilizador e conteúdo que requer autenticação. O modo de cache FORCE_CACHE_ALL não tem esta restrição.

Cabeçalhos das respostas personalizados

Com os cabeçalhos de resposta personalizados, pode especificar cabeçalhos que o Application Load Balancer clássico adiciona às respostas encaminhadas por proxy. Os cabeçalhos de resposta personalizados permitem-lhe refletir o estado da cache nos seus clientes, dados geográficos dos clientes e os seus próprios cabeçalhos de resposta estáticos.

Para ver instruções, consulte o artigo Configure cabeçalhos de resposta personalizados.

Chaves de cache

Cada entrada de cache numa cache da Cloud CDN é identificada por uma chave de cache. Quando um pedido chega à cache, esta converte o URI do pedido numa chave de cache e, em seguida, compara-o com as chaves das entradas em cache. Se encontrar uma correspondência, a cache devolve o objeto associado a essa chave.

Para os serviços de back-end, o Cloud CDN usa por predefinição o URI do pedido completo como a chave de cache. Por exemplo, https://example.com/images/cat.jpg é o URI completo de um pedido específico do objeto cat.jpg. Esta string é usada como a chave de cache predefinida. Apenas os pedidos com esta string exata correspondem. Os pedidos de http://example.com/images/cat.jpg ou https://example.com/images/cat.jpg?user=user1 não correspondem.

Para os contentores de back-end, a predefinição é que a chave da cache seja composta pelo URI sem o protocolo nem o anfitrião. Por predefinição, apenas os parâmetros de consulta conhecidos do Cloud Storage são incluídos como parte da chave da cache (por exemplo, "generation").

Assim, para um determinado contentor de back-end, os seguintes URIs resolvem para o mesmo objeto em cache:

  • 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

Pode alterar as partes do URI que são usadas na chave da cache. Embora o nome do ficheiro e o caminho tenham sempre de fazer parte da chave, pode incluir ou omitir qualquer combinação de protocolo, anfitrião ou string de consulta quando personalizar a chave da cache. Usar chaves de cache descreve como personalizar as suas chaves de cache.

Parte do URI Personalização Exemplos de URLs que têm a mesma chave de cache
Protocolo Omita o protocolo da chave de cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Anfitrião Omita o anfitrião da chave de cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String de consulta

Omita a string de consulta da chave da cache.

Omitir ou incluir seletivamente partes da string de consulta.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Além de incluir ou omitir toda a string de consulta, pode usar partes da string de consulta através de listas de inclusão e listas de exclusão.

Lista de inclusão de strings de consulta

Pode controlar seletivamente os parâmetros da string de consulta que o Cloud CDN incorpora nas chaves da cache. Por exemplo, se criar uma lista de inclusão de user, https://example.com/images/cat.jpg?user=user1&color=blue cria uma chave de cache de https://example.com/images/cat.jpg?user=user1 que também corresponde a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opção, tem de incluir a string de consulta, especificar uma lista de inclusão não vazia e não especificar uma lista de exclusão.

Lista de inclusão de strings de consulta para chaves da cache do Cloud Storage

A inclusão de parâmetros de consulta de URL em chaves de cache para contentores do Cloud Storage ajuda a suportar a não reutilização de consultas em cache. A limpeza da cache permite que um utilizador obtenha uma nova versão do ficheiro que foi carregado, mesmo que a versão anterior ainda esteja em cache válida com base na definição de TTL.

Pode usar uma lista de inclusão com parâmetros de string de consulta na chave da cache usada para publicar respostas a partir de um contentor de back-end. Embora o Cloud Storage não publique conteúdo diferente nem faça o encaminhamento com base em parâmetros de consulta, pode optar por incluir parâmetros que lhe permitam limpar a cache de conteúdo estático armazenado em contentores do Cloud Storage.

Por exemplo, pode anexar um parâmetro de consulta ?version=VERSION ou ?hash=HASH com base no conteúdo subjacente. Isto limita a necessidade de invalidar proativamente o conteúdo e alinha-se com os fluxos de trabalho de desenvolvimento Web modernos, em que as estruturas Web e os URLs usam um hash do conteúdo para evitar a publicação de objetos desatualizados em implementações.

Uma vez que a inclusão de parâmetros de consulta na chave de cache é apenas opcional, o Cloud CDN não suporta a exclusão de parâmetros de consulta de uma chave de cache para um contentor de back-end.

Lista de exclusões de strings de consulta

Pode controlar seletivamente os parâmetros da string de consulta que o Cloud CDN ignora através de uma lista de exclusão. Por exemplo, se criar uma lista de exclusões de user, todos os parâmetros da string de consulta exceto user são usados na chave da cache.

Com a lista de exclusões configurada e uma entrada de https://example.com/images/cat.jpg?user=user1&color=blue, o Cloud CDN cria uma chave de cache de https://example.com/images/cat.jpg?color=blue que também corresponde a https://example.com/images/cat.jpg?user=user2&color=blue, mas não a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opção, tem de incluir a string de consulta, especificar uma lista de exclusão não vazia e não especificar uma lista de inclusão.

Ordem dos parâmetros de consulta

A chave de cache gerada não depende da ordem dos parâmetros de consulta.

Por exemplo, os seguintes parâmetros de consulta geram a mesma chave da cache:

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

Definições de cabeçalhos HTTP e cookies HTTP

Pode melhorar as taxas de acertos da cache e a transferência de carga da origem com as seguintes definições de configuração da chave de cache:

  • Para serviços de back-end e contentores: use cabeçalhos HTTP como parte das chaves de cache incluindo cabeçalhos com nomes na configuração da chave de cache.
  • Apenas para serviços de back-end: use cookies HTTP com nome como chaves de cache, como para testes A/B (multivariáveis), testes canary e cenários semelhantes.

Os pedidos de cache que incluem cabeçalhos HTTP ou cookies HTTP adicionais no pedido são colocados em cache no terceiro pedido numa localização de cache para essa chave de cache. Isto reduz o impacto dos valores de cabeçalho ou de cookies de alta cardinalidade nas taxas de remoção da cache. Em circunstâncias normais e condições de tráfego do utilizador, isto não deve ser percetível e ajuda a garantir que o conteúdo popular permanece em cache.

Inclua cabeçalhos do pedido

Para colocar em cache variações adicionais de uma resposta, pode incluir cabeçalhos de pedidos adicionais na chave de cache.

Alguns cabeçalhos não são permitidos em chaves de cache porque têm, normalmente, uma cardinalidade muito elevada. Na maioria dos casos, os valores destes cabeçalhos são únicos por utilizador (Cookie,Authorization) ou têm milhares de valores prováveis (Referer, User-Agent, Accept). Por exemplo, o cabeçalho User-Agent pode ter mais de 5000 valores únicos, dada a grande variedade de navegadores, dispositivos de utilizador e sistemas operativos. Estes tipos de cabeçalhos teriam um impacto negativo grave nas taxas de acerto da cache.

Apenas são aceites nomes de campos de cabeçalho HTTP válidos de acordo com a RFC 7230. Os nomes dos campos de cabeçalho não são sensíveis a maiúsculas e minúsculas, e os duplicados são rejeitados.

Opcionalmente, pode configurar o servidor de origem para incluir cabeçalhos de pedidos de chave de cache configurados na resposta Vary. Não é obrigatório para o Cloud CDN, mas pode ser útil para caches a jusante. Para mais informações, consulte o artigo Variação dos cabeçalhos.

O Cloud CDN não permite que os seguintes cabeçalhos sejam incluídos na lista de cabeçalhos:

  • Accept
  • Accept-Encoding
  • Authority, porque esta opção é controlada pela configuração (cdnPolicy.includeHost)
  • Authorization, normalmente por utilizador, como nos símbolos OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, frequentemente por cliente ou por proxy
  • From
  • Host, porque esta opção é controlada pela configuração (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since ou If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (ou Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken e X-CSRF-Token, conforme usado por Django e Ruby on Rails
  • X-Forwarded-For, frequentemente por cliente ou por proxy
  • X-User-IP
  • Qualquer cabeçalho que comece com o seguinte:
    • Access-Control-, como Access-Control-Request-Headers e Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Use variáveis personalizadas com cabeçalhos de pedidos

As chaves de cache são úteis quando precisa de publicar conteúdo de forma diferente com base no dispositivo e na localização de cada utilizador. Por exemplo, pode permitir que um Website dinâmico publique as imagens adequadas para os utilizadores que estão a ver conteúdo com base no tipo de dispositivo ou definir um idioma predefinido útil com base na respetiva localização. Pode definir chaves de cache através de cabeçalhos de pedidos personalizados e variáveis personalizadas.

Para usar variáveis personalizadas com cabeçalhos de pedidos, faça o seguinte:

  1. Defina um cabeçalho de pedido personalizado para o seu serviço de back-end. Inclua uma ou mais variáveis para o valor do cabeçalho do pedido personalizado.
  2. Atualize a chave da cache para usar o cabeçalho do pedido personalizado.

Para o Cloud CDN, só pode usar as seguintes variáveis quando definir cabeçalhos que sejam cabeçalhos de pedidos personalizados e cabeçalhos de chaves de cache:

  • device_request_type
  • user_agent_family
  • client_region
  • client_region_subdivision

A CDN da nuvem limita as variáveis para ajudar a manter o desempenho da cache. Isto é semelhante aos limites nos cabeçalhos que podem ser usados como chaves de cache.

Por exemplo, se pudesse especificar X-Lat-Long:{client_city_lat_long} como um cabeçalho de pedido personalizado e, em seguida, adicionar X-Lat-Long ao seu conjunto de cabeçalhos de chave de cache, o Cloud CDN tentaria colocar em cache uma cópia da resposta para cada valor de client_city_lat_long. Isto levaria, em última análise, a uma utilização excessiva da cache, à eliminação desnecessária de conteúdo e a uma redução da oportunidade de devolver resultados da cache.

Por estes motivos, as variáveis com cardinalidade elevada não são incluídas na lista de variáveis usadas para definir cabeçalhos de pedidos personalizados e, posteriormente, chaves de cache.

Mesmos cabeçalhos com valores diferentes

Suponhamos que o utilizador envia vários cabeçalhos com o mesmo nome, mas com valores de cabeçalho diferentes. Por exemplo:

My-Header: Value1
My-Header: Value2

Neste caso, a RFC de multimédia na nuvem modifica o pedido partindo do princípio de que o cabeçalho tem de seguir a convenção padrão que permite que alguns cabeçalhos tenham vários valores. O Cloud CDN reduz os mesmos a uma lista separada por vírgulas para enviar para o back-end, pelo que é como se o cliente tivesse enviado o seguinte:

My-Header: Value1, Value2

Inclua cookies com nome

Um cookie HTTP é um par name=value, e um pedido pode incluir vários cookies HTTP, separados por um ponto e vírgula na mesma linha ou como cabeçalhos de pedidos Cookie discretos com um cookie por cabeçalho.

Pode fornecer uma lista de até cinco nomes de cookies.

Os agentes do utilizador (como os navegadores de Internet) limitam frequentemente o número de cookies armazenados por domínio a 4 KB. Certifique-se de que não envia demasiados cookies (ou cookies demasiado grandes), uma vez que o agente do utilizador pode não enviar todos os cookies num pedido. Isto pode afetar a receção de uma resposta específica em cache por parte de um utilizador.

Se estiver a publicar o seu conteúdo estático a partir de um nome de anfitrião diferente do que usa para emitir cookies, certifique-se de que o atributo Domain do cookie (e o atributo Path) permite que o cookie seja enviado juntamente com os pedidos de conteúdo estático.

Se um pedido incluir várias instâncias do mesmo nome de cookie, apenas a primeira é respeitada.

Diretivas de controlo de cache

As diretivas de controlo da cache HTTP afetam o comportamento da CDN do Google Cloud, conforme descrito na tabela seguinte.

N/A significa que uma diretiva não é aplicável a um pedido ou a uma resposta.

Diretiva Pedido Resposta
no-store Quando presente num pedido, o Cloud CDN respeita esta diretiva e não armazena a resposta na cache.

Uma resposta com no-store não é colocada em cache.

Isto pode ser substituído por backend com o FORCE_CACHE_ALL modo de cache.

no-cache A diretiva de pedido no-cache é ignorada para impedir que os clientes iniciem ou forcem potencialmente a revalidação para a origem.

Uma resposta com no-cache é colocada em cache, mas tem de ser revalidada com a origem antes de ser publicada.

Isto pode ser substituído por backend com o FORCE_CACHE_ALL modo de cache.

public N/A

Esta diretiva não é necessária para a capacidade de colocação em cache, mas é uma prática recomendada incluí-la para conteúdo que deve ser colocado em cache por proxies.

private N/A

Uma resposta com a diretiva private não é colocada em cache pelo Cloud CDN, mesmo que a resposta seja considerada colocável em cache. Os clientes (como os navegadores) podem continuar a colocar o resultado em cache.

Isto pode ser substituído por backend com o FORCE_CACHE_ALL modo de cache. Use no-store para impedir todo o armazenamento em cache de respostas.

max-age=SECONDS A diretiva de pedido max-age é ignorada. É devolvida uma resposta em cache como se este cabeçalho não estivesse incluído no pedido. Uma resposta com a diretiva max-age é colocada em cache até ao valor SECONDS definido.
s-maxage=SECONDS N/A

Uma resposta com a diretiva s-maxage é colocada em cache até ao SECONDS definido.

Se max-age e s-maxage estiverem presentes, s‑maxage é usado pelo Cloud CDN.

As respostas com esta diretiva não são apresentadas desatualizadas.

s-max-age (dois hífens) não é válido para fins de colocação em cache.

min-fresh=SECONDS A diretiva de pedido min-fresh é ignorada. É devolvida uma resposta em cache como se este cabeçalho não estivesse incluído no pedido. N/A
max-stale=SECONDS

A diretiva de pedido max-stale determina a obsolescência máxima (em segundos) que o cliente está disposto a aceitar.

A CDN na nuvem respeita esta diretiva e devolve uma resposta em cache desatualizada apenas se a resposta estiver desatualizada há menos tempo do que o especificado na diretiva max-stale. Caso contrário, volta a validar antes de publicar o pedido.

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

É apresentada uma resposta com stale-while-revalidate a um cliente durante um período máximo de SECONDS enquanto a revalidação ocorre de forma assíncrona.

Este comportamento pode ser ativado para todas as respostas definindo cdnPolicy.serveWhileStale no back-end.

stale-if-error=SECONDS A diretiva de pedido stale-if-error é ignorada. É devolvida uma resposta em cache como se este cabeçalho não estivesse incluído no pedido.

Este cabeçalho de resposta não tem efeito.

must-revalidate N/A

Uma resposta com must-revalidate é revalidada com o servidor de origem após expirar.

As respostas com esta diretiva não são apresentadas desatualizadas.

proxy-revalidate

Uma resposta com proxy-revalidate é revalidada com o servidor de origem após expirar.

As respostas com esta diretiva não são apresentadas desatualizadas.

immutable N/A Sem efeito. Isto é transmitido ao cliente na resposta.
no-transform N/A O Cloud CDN não aplica transformações.
only-if-cached A diretiva de pedido only-if-cached é ignorada. É devolvida uma resposta em cache como se este cabeçalho não estivesse incluído no pedido. N/A

Sempre que possível, a RFC do RFC do Cloud CDN (HTTP RFC 7234) esforça-se por estar em conformidade, mas favorece a otimização para a transferência de carga do cache e a minimização do impacto que os clientes podem ter na taxa de acertos e na carga de origem geral.

Para respostas que usam o cabeçalho Expires HTTP/1.1:

  • O valor do cabeçalho Expires tem de ser uma data HTTP válida, conforme definido no RFC 7231.
  • Um valor de data no passado, uma data inválida ou um valor de 0 indica que o conteúdo já expirou e requer revalidação.
  • Se um cabeçalho Cache-Control estiver presente na resposta, o Cloud CDN ignora o cabeçalho Expires.

A presença de um cabeçalho Expires válido e futuro na resposta permite que a resposta seja colocada em cache e não requer que outras diretivas de cache sejam especificadas.

O cabeçalho Pragma HTTP/1.0, se presente numa resposta, é ignorado e transmitido tal como está ao cliente. Os pedidos do cliente com este cabeçalho são transmitidos à origem e não afetam a forma como uma resposta é publicada pela RFC do Google Cloud.

Vary cabeçalhos

O cabeçalho Vary indica que a resposta varia consoante os cabeçalhos do pedido do cliente. Além do URI do pedido, o Cloud CDN respeita os cabeçalhos Vary que os servidores de origem incluem nas respostas. Por exemplo, se uma resposta especificar Vary: Accept, o Cloud CDN usa uma entrada de cache para pedidos que especificam Accept: image/webp,image/*,*/*;q=0.8 e outra para pedidos que especificam Accept: */*.

A tabela na secção Conteúdo não colocável em cache apresenta os cabeçalhos Vary que permitem que o conteúdo seja colocado em cache. Outros valores de cabeçalho Vary impedem que o conteúdo seja colocado em cache.

O modo de cache FORCE_CACHE_ALL não substitui este comportamento. Os cabeçalhos Vary são importantes para evitar o envenenamento da cache entre várias respostas possíveis do servidor de origem. Seria perigoso para FORCE_CACHE_ALL fazer com que essas respostas fossem colocadas em cache.

Os cabeçalhos Vary são, por vezes, usados quando publicam conteúdo comprimido. A RFC não comprime nem descomprime as respostas (a menos que a compressão dinâmica esteja ativada), mas pode publicar respostas que o servidor de origem comprimiu. Se o seu servidor de origem escolher se publica conteúdo comprimido ou não comprimido com base no valor do cabeçalho de pedido Accept-Encoding, certifique-se de que a resposta especifica Vary: Accept-Encoding.

Quando usa cabeçalhos HTTP na chave da cache, o Cloud CDN armazena em cache várias cópias da resposta com base nos valores dos cabeçalhos de pedido especificados, de forma semelhante ao suporte de Vary, mas sem a necessidade de o servidor de origem especificar explicitamente qualquer cabeçalho de resposta Vary. Se a origem especificar os cabeçalhos da chave de cache na resposta Vary, o Cloud CDN trata a resposta corretamente, tal como se os cabeçalhos não fossem mencionados na resposta Vary.

Tempos de expiração e pedidos de validação

O tempo de validade de uma entrada de cache define durante quanto tempo uma entrada de cache permanece válida. O valor fornecido pelo valor s-maxage (ou max-age ou expires) permite a revalidação automática do conteúdo em cache desatualizado gerado pelo utilizador.

Quando a RFC na nuvem recebe um pedido, procura a entrada de cache correspondente e verifica a respetiva antiguidade. Se a entrada de cache existir e for suficientemente recente, a resposta pode ser fornecida a partir da cache. Se o tempo de expiração tiver passado, o Cloud CDN tenta validar novamente a entrada da cache contactando um dos seus back-ends. Isto é feito antes de publicar a resposta, a menos que ative a opção serve-while-stale, caso em que a revalidação é realizada de forma assíncrona.

Para alguns modos de cache, pode definir valores TTL. Para mais informações, consulte o artigo Usar definições e substituições de TTL.

O modo de cache afeta a forma como a atualidade é determinada.

Modo de cache Comportamento de validação
CACHE_ALL_STATIC Os cabeçalhos de origem (cabeçalhos Cache-Control: s-maxage, Cache-Control: max-age ou Expires) são consultados para determinar a atualidade. Para conteúdo estático, se os cabeçalhos de origem não estiverem presentes, o valor default_ttl configurado determina a atualização. Após o conteúdo estático ter mais de default_ttl, o Cloud CDN volta a validá-lo.
USE_ORIGIN_HEADERS Cada entrada de cache numa cache do Cloud CDN tem um prazo de validade definido pelos cabeçalhos Cache-Control: s-maxage, Cache-Control: max-age ou Expires, de acordo com a RFC 7234.
FORCE_CACHE_ALL Em vez dos cabeçalhos de origem, o default_ttl configurado determina a atualidade. Após o conteúdo ter mais de default_ttl, a RFC na nuvem volta a validá-lo.

Se estiverem presentes mais do que um, Cache-Control: s-maxage tem prioridade sobre Cache-Control: max-age e Cache-Control: max-age tem prioridade sobre Expires.

Por predefinição, quando o valor do tempo de expiração excede 30 dias (2 592 000 segundos), a RFC na nuvem trata o valor de expiração como se fosse 2 592 000 segundos. Os clientes a jusante continuam a ver os valores precisos de max-age e s-maxage, mesmo que excedam 30 dias.

Despejo

Não existe garantia de que uma entrada na cache permaneça na cache até expirar, porque as entradas menos populares podem ser removidas antes de expirarem em qualquer altura para dar lugar a novo conteúdo. Como limite superior, as entradas da cache às quais não se acede durante 30 dias são removidas automaticamente.

Para mais informações, consulte o artigo Remoção e expiração.

Use pedidos condicionais para validação

O Cloud CDN pode tentar usar as informações nos cabeçalhos de resposta em cache para validar a entrada de cache com o back-end. Isto acontece quando ambos os seguintes requisitos são verdadeiros:

  • A resposta em cache anterior tem um cabeçalho Last-Modified ou ETag.
  • O pedido do cliente é um pedido GET que não contém cabeçalhos If-Modified-Since nem If-None-Match.

A RFC na nuvem realiza esta validação de forma ligeiramente diferente consoante a resposta tenha sido colocada em cache através de pedidos de intervalo de bytes:

  • Se a resposta tiver sido colocada em cache através de pedidos de intervalo de bytes, o Cloud CDN inicia um pedido de validação separado que inclui os cabeçalhos If-Modified-Since e If-None-Match.
  • Caso contrário, o Cloud CDN adiciona os cabeçalhos If-Modified-Since e If-None-Match ao pedido do cliente e encaminha o pedido modificado para o back-end.

Se a cópia em cache ainda estiver atualizada, o back-end pode validar a entrada de cache existente enviando uma resposta 304 Not Modified. Neste caso, o back-end envia apenas os cabeçalhos de resposta e não o corpo da resposta. O Cloud CDN insere os novos cabeçalhos de resposta na cache, atualiza o tempo de expiração e apresenta os novos cabeçalhos de resposta e o corpo da resposta em cache ao cliente.

Se a resposta em cache anterior não tiver um cabeçalho Last-Modified ou ETag, a RFC ignora a entrada em cache expirada e encaminha o pedido do cliente para o back-end sem alterações.

Suporte para pedidos de intervalo de bytes

Uma resposta que satisfaça os seguintes critérios indica que o servidor de origem suporta pedidos de intervalo de bytes:

  • Código de estado: 200 OK ou 206 Partial Content
  • Cabeçalho: Accept-Ranges: bytes
  • Cabeçalho: Content-Length e, para uma resposta 206 Partial Content, um valor Content-Range que indica o comprimento completo do objeto de origem. Por exemplo, Content-length: 0-100/999 é armazenável em cache, enquanto Content-length: 0-100/* não é.
  • Cabeçalho: Last-Modified e ETag com um validador forte.

O Cloud Storage suporta pedidos de intervalo de bytes para a maioria dos objetos. No entanto, o Cloud Storage não suporta pedidos de intervalo de bytes para objetos com metadados Content-Encoding: gzip, a menos que o pedido do cliente inclua um cabeçalho Accept- Encoding: gzip. Se tiver objetos do Cloud Storage com mais de 10 MB, certifique-se de que não têm metadados.Content-Encoding: gzip Para obter informações sobre como editar metadados de objetos, consulte o artigo Visualizar e editar metadados de objetos.

O software de servidor Web popular também suporta pedidos de intervalo de bytes. Consulte a documentação do seu servidor Web para ver detalhes sobre como ativar o suporte. Para mais informações sobre pedidos de intervalo de bytes, consulte a especificação HTTP.

Quando um servidor de origem suporta pedidos de intervalo de bytes, uma cache da RFC recusa-se a armazenar uma resposta que, de outra forma, seria armazenável em cache na primeira vez que é pedida se qualquer uma das seguintes condições for verdadeira:

  • O corpo da resposta está incompleto porque o cliente pediu apenas parte do conteúdo.
  • O corpo da resposta é superior a 1 MB (1 048 576 bytes).

Quando isto acontece e a resposta satisfaz os requisitos de capacidade de colocação em cache normais, a cache regista que o servidor de origem suporta pedidos de intervalo de bytes para essa chave de cache e encaminha a resposta do servidor de origem para o cliente.

Quando não encontra o conteúdo na cache, esta verifica se o servidor de origem suporta pedidos de intervalo de bytes. Se souber que os pedidos de intervalo de bytes são suportados para a chave de cache, a cache não encaminha o pedido do cliente para o Application Load Balancer externo. Em alternativa, a cache inicia os seus próprios pedidos de preenchimento da cache de intervalo de bytes para as partes em falta do conteúdo.

O servidor de origem devolve uma resposta 206 Partial Content quando o RFC inicia o seu próprio pedido de preenchimento da cache de intervalo de bytes. Para que uma resposta 206 Partial Content seja considerada durante o armazenamento em cache, tem de incluir um cabeçalho Content-Range com uma diretiva complete-length que não inclua asteriscos, por exemplo,0-100/999. Em seguida, a RFC na nuvem armazena em cache essa resposta 206 Partial Content devolvida e usa-a para responder a pedidos futuros de clientes para esse conteúdo.

Uma cache armazena uma resposta 206 Partial Content apenas quando é recebida em resposta a um pedido de intervalo de bytes iniciado pela cache. Uma vez que uma cache não inicia um pedido de intervalo de bytes, a menos que tenha registado anteriormente que o servidor de origem suporta pedidos de intervalo de bytes para essa chave de cache, uma determinada cache não armazena conteúdo superior a 1 MB até à segunda vez que esse conteúdo é acedido.

Devido à sua natureza distribuída, o Cloud CDN pode, por vezes, obter o bloco final da origem mais do que uma vez por localização. Isto só afeta os primeiros pedidos por chave de cache.

Solicitar a redução (união)

O pedido de redução (também denominado coalescing) reduz ativamente vários pedidos de preenchimento da cache iniciados pelo utilizador para a mesma chave de cache num único pedido de origem por nó de limite. Isto pode reduzir ativamente a carga na origem e aplica-se a pedidos de itens (respostas obtidas diretamente) e pedidos de fragmentos, em que o Cloud CDN usa pedidos Range para obter objetos maiores de forma mais eficiente.

A redução de pedidos está ativada por predefinição.

Os pedidos reduzidos comportam-se da seguinte forma:

  • Os pedidos reduzidos registam o pedido apresentado ao cliente e o pedido de preenchimento da cache (reduzido).
  • O líder da sessão reduzida é usado para fazer o pedido de preenchimento de origem.
  • Os atributos de pedido que não fazem parte da chave da cache, como o cabeçalho User-Agent ou Accept-Encoding, apenas refletem o líder da sessão reduzida.
  • Não é possível comprimir pedidos que não tenham a mesma chave de cache.

O diagrama seguinte mostra como os pedidos são unidos:

Cloud CDN com a redução de pedidos ativada.
Cloud CDN com a redução de pedidos ativada (clique para aumentar).

Em comparação, com a união de pedidos desativada ou para pedidos que não podem ser unidos, o número de pedidos de origem e respostas pode ser igual ao número de clientes que tentam obter um objeto que não está em cache.

O Cloud CDN sem a redução de pedidos ativada.
Cloud CDN sem a funcionalidade de redução de pedidos ativada (clique para aumentar).

Para todos os tipos de pedidos, a redução está ativada por predefinição. Para tipos de pedidos de itens, pode desativar a redução. Recomendamos que desative a redução para pedidos de itens em cenários altamente sensíveis à latência, como a publicação de anúncios, em que o carregamento de origem não é uma consideração.

A tabela seguinte resume o comportamento predefinido e a configurabilidade para diferentes tipos de pedidos.

Tipo de pedido Comportamento predefinido Configurável Vantagens da redução
Pedidos de fragmentos Ativado Não Pode reduzir significativamente a largura de banda de origem
Pedidos de artigos Ativado Sim Pode reduzir o volume de pedidos de origem

Para desativar a redução de pedidos de itens através da CLI do Google Cloud para um contentor de back-end que faça referência a um contentor do Cloud Storage:

gcloud

Use o comando gcloud compute backend-services ou backend-buckets:

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

Para ativar a redução de pedidos de itens num contentor de back-end através da CLI gcloud:

gcloud

Use o comando gcloud compute backend-buckets:

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

Para ativar a redução de pedidos de itens através da CLI do Google Cloud para um serviço de back-end, incluindo grupos de VMs e back-ends externos:

gcloud

Use o comando gcloud compute backend-services:

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

Pedidos iniciados pelo Cloud CDN

Quando o servidor de origem suporta pedidos de intervalo de bytes, o Cloud CDN pode enviar vários pedidos ao servidor de origem em reação a um único pedido do cliente. A RFC na nuvem pode iniciar dois tipos de pedidos: pedidos de validação e pedidos de intervalo de bytes.

Se a resposta que indicou que o seu servidor de origem suportava pedidos de intervalo de bytes para uma determinada chave de cache tiver expirado, a RFC inicia um pedido de validação para confirmar que o conteúdo não foi alterado e que o seu servidor de origem continua a suportar pedidos de intervalo para o conteúdo. Se o servidor de origem responder com uma resposta 304 Not Modified, o Cloud CDN continua a publicar o conteúdo através de intervalos de bytes. Caso contrário, a RFC do Google Cloud encaminha a resposta do servidor de origem para o cliente. Controla os prazos de validade através dos Cache-Control e dos Expires cabeçalhos de resposta.

Quando ocorre uma falha de cache, a RFC na nuvem inicia pedidos de preenchimento da cache para um conjunto de intervalos de bytes que se sobrepõem ao pedido do cliente. Se alguns intervalos do conteúdo pedido pelo cliente estiverem presentes na cache, o Cloud CDN apresenta o que puder a partir da cache e envia pedidos de intervalo de bytes apenas para os intervalos em falta para o seu servidor de origem.

Cada pedido de intervalo de bytes iniciado pelo Cloud CDN especifica um intervalo que começa num desvio múltiplo de 2 097 136 bytes. Com a possível exceção do intervalo final, cada intervalo também tem 2 097 136 bytes. Se o conteúdo não for um múltiplo desse tamanho, o intervalo final é mais pequeno. O tamanho e os deslocamentos usados em pedidos de intervalo de bytes podem mudar no futuro.

Por exemplo, considere um pedido de um cliente para os bytes 1 000 000 a 3 999 999 de conteúdo que não está presente na cache. Neste exemplo, a RFC na nuvem pode iniciar dois pedidos GET, um para os primeiros 2 097 136 bytes do conteúdo e outro para os segundos 2 097 136 bytes. Isto resulta em 4 194 272 bytes de preenchimento da cache, apesar de o cliente ter pedido apenas 3 000 000 bytes.

Quando usa um contentor do Cloud Storage como origem, cada pedido GET é faturado como uma operação de classe B separada. São-lhe cobrados todos os pedidos GET processados pelo Cloud Storage, incluindo os pedidos iniciados pela RFC de multimédia na nuvem. Quando uma resposta é publicada inteiramente a partir de uma cache da CDN do Google Cloud, não são enviados pedidos GET para o Google Cloud Storage, e não lhe são cobradas operações do Google Cloud Storage.

Quando a RFC inicia um pedido de validação ou um pedido de intervalo de bytes, não inclui cabeçalhos específicos do cliente, como Cookie ou User-Agent.

No campo Cloud Logging httpRequest.userAgent, Cloud-CDN-Google significa que a RFC de multimédia na nuvem iniciou o pedido.

Ignorar a cache

A ignorância da cache permite que os pedidos que contêm cabeçalhos de pedidos específicos ignorem a cache, mesmo que o conteúdo tenha sido colocado em cache anteriormente.

Esta secção fornece informações sobre como ignorar a cache com cabeçalhos HTTP, como Pragma e Authorization. Esta funcionalidade é útil quando quer certificar-se de que os seus utilizadores ou clientes têm sempre o conteúdo mais recente obtido diretamente do servidor de origem. Pode fazê-lo para testar, configurar diretórios de preparação ou scripts.

Se um cabeçalho especificado corresponder, a cache é ignorada para todas as definições do modo de cache, mesmo FORCE_CACHE_ALL. A ignorância da cache resulta num grande número de falhas de cache se os cabeçalhos especificados forem comuns a muitos pedidos.

Antes de começar

  • Certifique-se de que o Cloud CDN está ativado. Para obter instruções, consulte o artigo Usar o Cloud CDN.

  • Se necessário, atualize para a versão mais recente da CLI Google Cloud:

    gcloud components update

Configure a ignorância da cache

Pode especificar até cinco nomes de cabeçalhos HTTP. Os valores não são sensíveis a maiúsculas e minúsculas. O nome do cabeçalho tem de ser um token de campo de cabeçalho HTTP válido. Um nome de cabeçalho não pode aparecer mais do que uma vez na lista de cabeçalhos adicionados. Para consultar as regras sobre nomes de cabeçalhos válidos, consulte o artigo Como funcionam os cabeçalhos personalizados.

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda à página Balanceamento de carga

  2. Clique no nome do seu Application Load Balancer externo.
  3. Clique em Editar .
  4. Em Configuração de back-end, selecione um back-end e clique em Editar .
  5. Certifique-se de que a opção Ativar RFC está selecionada.
  6. Na parte inferior da janela, clique em Configurações avançadas.
  7. Em Ignorar cache no cabeçalho do pedido, clique em Adicionar cabeçalho.
  8. Escreva um nome de cabeçalho, como Pragma ou Authorization.
  9. Clique em Atualizar.
  10. Clique novamente em Atualizar.

gcloud

Para buckets de back-end, use o comando gcloud compute backend-buckets create ou gcloud compute backend-buckets update com a flag --bypass-cache-on-request-headers.

Para serviços de back-end, use o comando gcloud compute backend-services create ou gcloud compute backend-services update com a flag --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 exemplo:

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

API

Para buckets de back-end, use a chamada API Method: backendBuckets.insert, Method: backendBuckets.update, ou Method: backendBuckets.patch.

Para serviços de back-end, use a chamada API Method: backendServices.insert, Method: backendServices.update ou Method: backendServices.patch.

Por exemplo:

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

Adicione o seguinte fragmento ao corpo do pedido JSON:

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

Desative a ignorância da cache

gcloud

Para buckets de back-end, use o comando gcloud compute backend-buckets create ou gcloud compute backend-buckets update com a flag --no-bypass-cache-on-request-headers.

Para serviços de back-end, use o comando gcloud compute backend-services create ou gcloud compute backend-services update com a flag --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

Para buckets de back-end, use a chamada API Method: backendBuckets.insert ou Method: backendBuckets.update.

Para serviços de back-end, use a chamada da API Method: backendServices.insert ou Method: backendServices.update.

Use uma das seguintes chamadas da 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

Adicione o seguinte fragmento ao corpo do pedido JSON:

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

O que se segue?