Cloudflare adiciona suporte ao header Vary nas Cache Rules

O que foi lançado

A Cloudflare anunciou suporte ao header HTTP Vary em suas Cache Rules, disponível em todos os planos (Free, Pro, Business e Enterprise), configurável pelo dashboard, Rulesets API e Terraform. Com isso, a origem continua declarando quais headers de requisição podem afetar a resposta, mas o cliente decide como a Cloudflare trata cada um deles.

Por que o Vary é problemático

O header Vary indica a caches intermediárias quais campos da requisição podem influenciar a resposta - por exemplo, servir HTML para navegadores e JSON para clientes de API a partir da mesma URL. Sem ele, a primeira resposta em cache pode ser entregue ao cliente errado. O problema central, como descreve o post, é que o Vary diz quais campos podem afetar a resposta, mas não quais diferenças realmente importam. Uma origem que atende apenas inglês, francês e alemão recebe milhares de combinações de Accept-Language, mas produz só três representações; um cache que compara valores brutos pode criar variantes separadas para respostas idênticas.

Essa fragmentação escala rápido: dez valores em um campo criam dez variantes; dez valores em três campos podem criar 1.000 combinações. Headers como User-Agent e cookies têm cardinalidade muito maior. O resultado é um cache tecnicamente correto e quase inútil - entradas frias que competem por capacidade, se expulsam mutuamente, reduzem a taxa de acerto e geram mais requisições à origem. Uma análise citada de mais de 120 milhões de respostas de cerca de 50 mil sites populares encontrou quase 3 mil sites variando em quatro ou mais campos, alguns em 10, 23 ou até 47. O post ressalta que parte dessa variação de alta cardinalidade é deliberada, como partição geográfica feita por CDNs com valores controlados.

Como o novo controle funciona

A configuração se divide em duas decisões: a origem usa Vary para nomear os headers; a Cache Rule define a ação para cada um. Há três ações:

• normalize (recomendada como padrão): normaliza headers de negociação antes de selecionar a variante, agregando requisições equivalentes. Para Accept, Accept-Language e Accept-Encoding, aplica regras específicas - minúsculas, ordenação por quality value com desempate alfabético e filtragem aos formatos e idiomas configurados. Tags regionais como en-US reduzem a en, salvo configuração. Para outros headers, apenas remove espaços opcionais e combina linhas repetidas.
• passthrough: usa os bytes brutos do header para o casamento no cache, preservando maiúsculas, espaços e ordem - indicado para valores controlados em que a diferença exata muda a resposta.
• bypass: não armazena a resposta quando a origem nomeia aquele header - indicado para headers personalizados ou sem limite, como Cookie e User-Agent. Entradas existentes não são removidas automaticamente.

Se a origem não retorna Vary, a resposta é cacheada normalmente. Vary: * sempre ignora o cache. A Cloudflare encaminha os valores normalizados de Accept e Accept-Language à origem para manter o casamento de cache alinhado com a seleção feita pela origem.

Detalhes operacionais e ressalvas

O post destaca responsabilidades importantes: toda resposta cacheável que possa variar precisa retornar Vary de forma consistente, incluindo erros e fallbacks; uma única omissão pode fazer a Cloudflare cachear a resposta sem o isolamento necessário. A normalização pode descartar exclusões q=0 (por exemplo, en-US;q=0 pode virar en), então origens que dependem dessas exclusões devem usar passthrough. Purges de um recurso cobrem todas as suas variantes de Vary, e mudar a configuração não limpa conteúdo antigo automaticamente - chaves novas podem gerar misses até que entradas antigas expirem.

Por que não chave de cache customizada

Uma custom cache key adiciona as dimensões configuradas a toda resposta coberta pela regra, mesmo quando a origem não as usou. A recomendação é usar chave customizada quando uma propriedade da requisição sempre define o recurso, e Vary quando a origem declara o mesmo conjunto de campos em todas as respostas cacheáveis - evitando duplicar o mesmo header nos dois mecanismos sem testes deliberados.

Conclusão

A Cloudflare posiciona o recurso como ponte entre a visão da origem (quais respostas pode servir) e a do cache (quais requisições podem reutilizar cada resposta). A empresa reconhece que configurar formatos e idiomas manualmente pode não atender toda aplicação e diz estar avaliando ideias do draft expirado Availability Hints, que permitiria origens descrever diretamente as representações que servem.