Resumo

  • No-Vary-Search deixa a origem declarar que certas chaves ou a ordem delas não diferenciam respostas para a correspondência de cache. Frescor, validação, Vary, autorização e os demais requisitos continuam valendo.
  • O campo não apaga parâmetros nem reescreve a URL. Uma equivalência falsa pode impedir que a origem veja o novo pedido e levar um cache compartilhado a servir uma resposta obtida em outro contexto.

Considere /preco?produto=27&utm_source=email e /preco?utm_source=evento&produto=27. A aplicação sabe que utm_source não altera o preço e que a ordem das chaves é indiferente. Para o cache, porém, os destinos são distintos. Inferir equivalência por conta própria seria transformar observação de tráfego em autoridade sobre a aplicação.

O draft-ietf-httpbis-no-vary-search-09, de 17 de agosto de 2026, oferece uma declaração explícita. Em 29 de agosto, continua um Internet-Draft ativo do HTTPBIS, destinado a Proposed Standard, aprovado no IESG e aguardando anúncio com acompanhamento do Area Director. Ainda não é RFC, e No-Vary-Search ainda não aparece no registro da IANA de nomes de campos HTTP.

É possível experimentar com essa versão, mas não tratá-la como texto imutável. O documento prova a gramática proposta e seus limites. Não prova suporte efetivo de um CDN, correção da classificação da origem nem ausência de vazamento.

A separação exata vem primeiro

RFC 9111 exige, para reutilizar uma resposta armazenada, correspondência do método e da URI de destino, dos campos indicados por Vary, além de frescor ou validação e controles que permitam o uso. Consultas diferentes normalmente significam URIs diferentes.

O protocolo não sabe se user, token ou campaign é decorativo. Nomes amigáveis e amostras com corpos iguais não demonstram que uma chave nunca influencie roteamento, autorização, faturamento ou comportamento futuro.

O novo campo altera apenas a etapa de correspondência da URI. Não renova conteúdo vencido, não cancela Vary, não torna pública uma resposta privada e não concede acesso. Depois da equivalência, todas as demais condições de RFC 9111 ainda precisam ser satisfeitas.

Um dicionário pequeno define a fronteira

O valor é um Dictionary de RFC 9651. key-order é Boolean. params lista nomes ignorados; except faz o inverso e preserva variação somente nos nomes listados. params e except não podem coexistir.

A origem emite o campo porque detém a semântica. Um intermediário não deve inserir, apagar ou modificar a declaração, salvo quando atua como origem daquela resposta. Uma regra criada pelo CDN a partir de corpos semelhantes deslocaria a decisão para quem menos conhece a finalidade do parâmetro.

O erro fecha a porta. Valor ausente, inválido ou contraditório volta à consulta exata, sensível à ordem. Perdem-se acertos, não isolamento. Chaves desconhecidas do Dictionary são ignoradas; por isso, extensões futuras só podem ampliar equivalências. Uma restrição exigirá outro campo para que implementações antigas não reutilizem demais.

A comparação decodifica a consulta

A equivalência nunca atravessa esquema, host, porta ou caminho. Dentro dessa fronteira, uma configuração não padrão analisa a consulta pelo modelo WHATWG application/x-www-form-urlencoded, remove pares ignorados ou retém os de except, ordena chaves quando autorizado e compara chaves e valores, preservando duplicatas.

Percentuais são decodificados, + vira espaço e segmentos vazios seguem o algoritmo de formulário. UTF-8 inválido pode virar U+FFFD e fazer bytes diferentes convergirem na mesma chave. Ao mesmo tempo, não há normalização Unicode: formas NFC e NFD continuam distintas.

Se uma assinatura usa os bytes originais, o roteador lê a ordem de duplicatas ou um valor vazio representa consentimento, essa diferença é crítica. O próprio rascunho desaconselha o campo para consultas fora do modelo form-urlencoded. RFC 6943 mostra o problema geral de comparar identificadores sob regras diferentes; aqui o falso positivo seleciona uma resposta real.

O cache mantém a escolha local

Um cache compatível pode usar a comparação ampliada, mas não é obrigado. Pode procurar primeiro a chave exata, indexar uma chave simplificada ou recusar o hit. A origem oferece conhecimento; o cache que assume a consequência preserva a decisão de reutilização.

Se respostas do mesmo host e caminho carregam configurações não vazias conflitantes, o rascunho permite preferir a vinculada a um Date mais recente. Isso favorece convergência, mas não prova correção. Uma política ruim também pode ser a mais nova, e uma implantação gradual produz visões diferentes.

A invalidação de RFC 9111 não é ampliada automaticamente. Após uma mutação, o cache pode invalidar URIs equivalentes, porém não precisa. Entradas tratadas como iguais na leitura podem sobreviver de modo diferente na escrita. Um parâmetro usado para quebrar o cache também falha se estiver na lista ignorada; caminho ou arquivo endereçado por conteúdo continua sendo outra escolha.

Os identificadores continuam circulando

O navegador exibe a URL completa e pode guardá-la no histórico. CDN, proxy, logs e analytics continuam recebendo os parâmetros. No-Vary-Search muda a correspondência de cache; não é limpeza de privacidade, redirecionamento ou canonicalização.

Um cache privado pode evitar o processamento de uma etiqueta pela origem. Um cache compartilhado ainda vê o pedido e pode ampliar o conjunto que recebe uma resposta armazenada. Nunca se deve ignorar uma chave que governe identidade, autorização, assinatura, consentimento, roteamento, auditoria, cobrança, revogação ou qualquer processamento necessário à reutilização segura.

O corpo pode ser igual enquanto o direito de obtê-lo é diferente. Uma imagem assinada pode ter pixels idênticos; a assinatura ainda controla acesso. Numa falha extrema, Alice recebe conteúdo buscado para Bob. Diretivas private e partições corretas seguem essenciais, mas não tornam aceitável uma equivalência falsa.

A prova precisa registrar o pedido que não chegou

O registro operacional deve ligar a URL solicitada à URL armazenada, ao campo bruto, à configuração analisada, aos pares comparados, à entrada escolhida, aos demais testes de RFC 9111, ao contexto de usuário e partição, ao bypass da origem e à impressão do corpo entregue. Uma taxa de hits não distingue equivalência correta de vazamento eficiente.

A especificação comum mínima de Lu Heng distribui bem a autoridade: o núcleo compartilhado contém dicionário e comparação; a aplicação conserva a decisão futura sobre suas chaves; a adoção permanece voluntária para cada cache. A primazia do código em execução desloca a prova da configuração para a entrada realmente selecionada e o resultado entregue.

Sua distinção entre soberania de dados técnica e prática também importa. A origem controla formalmente o campo, mas navegador, CDN e cache mantêm URL, logs e corpo; a origem pode nem ver o segundo pedido. A governança precisa acompanhar essa custódia distribuída.

Quando há dúvida, o resultado seguro é um miss adicional. Reduzir a separação não é uma forma aceitável de incerteza.