Resumo

  • HTTP Vary indica campos da requisição que podem ter influenciado a representação escolhida pela origem; antes de reutilizar a resposta sem validação, o cache precisa comparar os campos indicados.
  • O campo não comprova a configuração implantada, todos os critérios da aplicação, a separação de locatários ou autorizações, nem o resumo criptográfico da representação realmente entregue.

Imagine uma plataforma que fornece configurações específicas de cada locatário em um URI compartilhado. O locatário A pede o recurso, a origem devolve sua identidade visual e responde com Vary: Accept-Encoding. Um painel de garantia encontra um Vary válido e marca o isolamento como aprovado. Mais tarde, o locatário B usa a mesma preferência de codificação e recebe do cache de borda os bytes de A.

O Vary não falhou. Ele descreveu a dimensão que a origem declarou usar para selecionar aquela resposta. A falha está em transformar uma declaração limitada em prova de uma fronteira mais ampla que o campo nunca se propôs a certificar.

O que Vary realmente declara

A RFC 9110 define Vary como o campo de resposta que descreve quais partes da requisição, além do método e do URI de destino, podem ter influenciado a seleção do conteúdo pela origem. Quando o valor lista nomes de campos, eles são os campos de seleção. Trata-se de uma declaração da origem sobre possíveis entradas usadas para uma resposta específica.

O campo tem duas funções. Ele informa ao cache que a resposta não pode ser reutilizada para uma requisição posterior se os campos indicados não coincidirem, salvo validação pela origem. Também avisa ao agente de usuário que houve negociação de conteúdo e que outros valores podem produzir outra representação. Nenhuma função converte o cabeçalho em telemetria sobre o que o cache posteriormente armazenou ou serviu.

O curinga reforça o limite. Vary: * significa que fatores além dos campos nomeados, possivelmente o endereço de rede do cliente, podem ter participado da seleção. O destinatário não consegue decidir se a resposta serve a uma requisição futura apenas pelos campos e precisa encaminhá-la à origem. Um proxy não pode gerar o curinga. Ele expressa incerteza, não aciona isolamento universal.

A chave efetiva é outro fato

A RFC 9111 chama de chave de cache a informação usada pelo cache para escolher uma resposta armazenada. No mínimo, ela envolve o método e o URI de destino. O cache pode acrescentar os campos indicados pelo Vary e outros dados próprios.

Quando a resposta armazenada traz Vary, o cache não deve reutilizá-la sem validação a menos que todos os campos indicados correspondam aos da requisição que originou o armazenamento. Só é permitido normalizar diferenças quando a semântica do campo continua igual. A ausência de um campo indicado corresponde apenas a outra ausência. Uma resposta armazenada com Vary: * nunca corresponde.

São regras robustas, mas não respondem a quatro perguntas operacionais. O cache implantado interpretou e aplicou o campo? Algum intermediário o removeu ou reescreveu? A aplicação escolheu conteúdo por uma entrada não declarada, como o locatário resolvido após a autenticação? O objeto entregue foi a variante que o cache acreditava ter escolhido? O Vary é evidência relevante, mas não é a resposta completa.

O isolamento pode depender de dimensões invisíveis

Aplicações podem selecionar representações por conta autenticada, mapeamento de locatário, coorte funcional, versão de política, jurisdição ou configuração de borda. Alguns fatos aparecem em campos da requisição; outros vêm do estado do servidor. Quando fatores externos à mensagem interferem, a RFC 9110 permite Vary: *, mas isso impede a reutilização comum em vez de descrever uma partição privada reutilizável.

Logo, a presença do Vary, ou uma lista apenas com idioma e codificação, não prova isolamento. Um campo sintaticamente correto pode estar incompleto diante da lógica da aplicação. Por outro lado, um cache pode acrescentar uma partição de privacidade que o Vary não revela. A resposta visível não mostra nenhum dos dois resultados.

O tema também difere de frescor. Uma variante pode estar fresca e ainda ser a errada porque faltou uma dimensão na chave. Pode estar obsoleta e continuar na partição correta. A revalidação pode confirmar o uso de uma representação pelos validadores HTTP sem demonstrar que a requisição entrou no locatário certo. Frescor, validação, autorização e seleção são controles relacionados, não equivalentes.

Evidência para uma afirmação defensável

Para afirmar que uma implantação manteve as representações isoladas, é preciso ligar a declaração de protocolo ao que o cache fez. Registre a instância ou coorte e a versão da configuração; método e URI; valor exato de Vary recebido pelo cache; valores normalizados e ausência de cada campo indicado; todas as dimensões usadas pela aplicação; contexto de locatário e autorização; decisão de acerto, falta (cache miss) ou revalidação; identidade do objeto armazenado; e resumo dos bytes entregues.

Esse recibo de seleção de variante é uma síntese editorial de evidências, não um elemento de protocolo definido pelo IETF. Ele impede que um sinal normativo estreito seja promovido a uma garantia operacional ampla. O ponto de observação também precisa ser preservado, pois origem, cache intermediário e borda podem ver campos e aplicar configurações diferentes.

O Vary continua útil quando seu limite é respeitado. Ele torna visível a negociação declarada e dá aos caches compatíveis obrigações concretas de comparação. O erro começa quando a declaração vira prova de implementação, isolamento ou resultado. Um cabeçalho pode informar as dimensões pretendidas; apenas a união entre configuração observada e entrega mostra que a representação correta permaneceu do lado correto da fronteira.

Fontes