A Cloudflare dividiu o cabeçalho Vary do HTTP naquilo que varia e em quanto importa

O cabeçalho Vary do HTTP informa aos caches quais cabeçalhos de requisição podem afetar uma resposta, para que um cache não sirva o HTML de um navegador a um cliente de API que pede JSON. A Cloudflare cita uma análise externa de mais de 120 milhões de respostas em quase 50.000 sites populares, que constatou quase 3.000 variando em quatro ou mais campos, alguns em 10, 23 ou até 47. O Vary está correto, mas, tomado ao pé da letra, pode tornar o cache quase inútil: dez valores em três campos já criam até 1.000 variantes, e cabeçalhos como Accept-Language podem diferir em ordem ou formatação embora signifiquem a mesma coisa para a origem.

O resultado é um cache que é 'perfeitamente correto e quase permanentemente frio': respostas idênticas byte a byte se dispersam por muitas entradas pouco reutilizadas, que se despejam mutuamente e empurram mais requisições de volta à origem. As soluções alternativas existentes — ignorar o cache por completo, duplicar a lógica de negociação em um Worker ou recursos restritos como o Vary para imagens — cada uma abria mão do cache, duplicava a lógica da aplicação ou cobria apenas um caso.

As Regras de Cache agora permitem que a origem continue declarando cabeçalhos Vary enquanto uma configuração de regra decide, por cabeçalho, se deve normalizar valores em um pequeno conjunto de equivalência, repassar valores exatos ou ignorar o cache para cabeçalhos imprevisíveis. Duas requisições Accept-Language, en-US, fr;q=0.8 e fr;q=0.8, en-GB, ambas preferindo inglês, agora podem compartilhar uma única entrada em cache sob normalização em vez de se tornarem duas variantes, enquanto um cabeçalho que precisa variar exatamente pode usar o repasse. Está disponível hoje nos planos Free até Enterprise.

Separar o que varia de quanto da variação conta

Normalizar Accept e Accept-Language ordenando pelo valor de qualidade e reduzindo a um conjunto configurado de formatos agrupa requisições que são diferentes byte a byte mas semanticamente idênticas em uma única entrada.

Fazer a escolha entre normalizar/repassar/ignorar por cabeçalho, e não globalmente, permite que um operador trate Cookie como ilimitado (ignorar) enquanto trata Accept-Language como um pequeno conjunto fechado (normalizar).

Encaminhar o valor normalizado do cabeçalho à origem, e não apenas usá-lo para a chave de cache, mantém a seleção de resposta da origem alinhada com a variante de cache em que ela é armazenada.

Vary: * ainda sempre ignora o cache, já que pode sinalizar fatores externos à mensagem HTTP, como o IP do cliente, que determinaram a resposta, os quais nenhuma regra em nível de cabeçalho pode normalizar com segurança.

Quando um mecanismo de correção explode em desperdício combinatório, encontre onde você está tratando 'bytes diferentes' e 'significado diferente' como a mesma coisa, e dê ao operador um controle separado para cada um.

A Cloudflare diz estar avaliando se ideias do rascunho expirado Availability Hints do IETF poderiam permitir que as origens descrevessem diretamente suas representações suportadas, reduzindo o trabalho manual de configurar quais formatos e idiomas uma Regra de Cache deve normalizar. O post enquadra a atual divisão entre normalizar/repassar/ignorar como o preenchimento de uma lacuna entre as opções existentes (ignorar totalmente, chaves de cache personalizadas ou lógica de negociação baseada em Worker), e não como um design final.