Resumo

  • O RFC 9111 recomenda que uma resposta com must-understand inclua também no-store. Quem não conhece a novidade a ignora, mas ainda recebe uma instrução conservadora já compreendida.
  • Entender um status exige reconhecê-lo e implementar todo o comportamento de cache especificado para ele. Ler o número ou analisar o nome da diretiva não comprova essa capacidade.
  • Ignorar no-store remove apenas uma vedação. Método, autorização, cache compartilhado, cacheabilidade, frescor e reutilização continuam sendo decisões separadas; privacidade também não é garantida.

A metade discreta da atualização

Considere uma resposta com Cache-Control: must-understand, no-store diante de dois caches.

O primeiro é anterior a must-understand. A regra de extensibilidade do HTTP manda ignorar diretivas de cache desconhecidas. Ele descarta a primeira, reconhece no-store e não guarda a resposta.

O segundo implementa a nova diretiva. Mesmo assim, não recebe autorização automática. Precisa reconhecer o código de status da resposta e executar todos os requisitos de cache definidos para ele. Só nessa condição o RFC 9111 recomenda ignorar o no-store acompanhante. Depois disso, ainda avalia as demais regras de armazenamento.

A combinação permite que o protocolo evolua sem uma troca simultânea de toda a infraestrutura. A origem não precisa conhecer cada intermediário. O software antigo encontra um comportamento de recuo que já domina; o novo usa prova local para entrar numa ramificação mais ampla.

O desenho desaparece quando a documentação cita apenas must-understand. O nome parece uma ordem universal, embora um cache que nunca o implementou seja obrigado a ignorá-lo. Sem no-store, não há recuo conservador fornecido pelo par. A unidade de implantação é a dupla, e o critério é comportamento comprovado, não presença textual.

Reconhecer não é entender

O RFC 9111 define entendimento de modo operacional: o cache reconhece o código de status e implementa todo o comportamento relacionado a cache especificado para ele.

Um analisador pode aceitar três algarismos. Uma interface pode exibir o nome. Um destinatário HTTP pode tratar um código desconhecido de acordo com sua classe. Essas funções não mostram que o mecanismo de cache aplicou a regra particular.

O contraste entre normas deixa isso claro. O RFC 6585 determina que respostas 428, 429, 431 e 511 não sejam armazenadas. O RFC 7538 define 308 Permanent Redirect como cacheável por padrão, salvo regra contrária do método ou de controles explícitos. Não é uma lista completa; é a evidência de que status diferentes podem exigir resultados diferentes.

Se um produto rotula 429 corretamente, mas o armazena como resposta ordinária, reconhece o status sem entendê-lo para os fins do RFC 9111. Um teste que verifica apenas o parser de must-understand também mede gramática, não conformidade.

O registro defensável separa cinco fatos: status recebido; reconhecimento; implementação de seus requisitos; suporte à diretiva; e resultado das condições restantes de armazenamento e reutilização. Um único campo “compatível” transforma uma condição verificável em autocertificação.

O freio antigo viabiliza o caminho novo

Caches devem ignorar diretivas desconhecidas para que uma extensão não quebre software já instalado. O RFC 9111 explica como uma extensão de comportamento funciona: a diretiva nova segue junto da antiga; o destinatário desinformado mantém o comportamento velho, e o informado entende como a novidade modifica a exigência anterior.

no-store é esse freio anterior. Não contradiz must-understand; cria o padrão seguro. O cache qualificado sabe em qual circunstância estreita pode afastá-lo.

A omissão muda o resultado. Se apenas must-understand for enviado, o cache antigo ignora o único sinal novo. Talvez deixe de armazenar por outra razão, mas a extensão já não lhe deu uma saída conservadora.

O texto normativo usa SHOULD para incluir no-store e também para ignorá-lo quando as condições são cumpridas. É uma recomendação forte, não um comando sem exceções e tampouco um detalhe opcional. Qualquer desvio precisa explicar o comportamento dos participantes antigos.

Retirar uma barreira não aprova o armazenamento

“Ignorar no-store” não significa “armazenar”. A exceção apenas subtrai uma proibição.

As outras condições da seção 3 continuam: o método precisa permitir; o status deve ser final; requisitos especiais devem ser entendidos; regras de Authorization e de caches compartilhados podem incidir; private continua valendo; e a resposta precisa de fundamento explícito ou definido pelo status para ser cacheável.

Reutilizar é uma decisão posterior. A entrada tem de corresponder à nova requisição e estar fresca, validada ou autorizada a ser servida obsoleta. must-understand não cria frescor, não valida conteúdo e não corrige uma chave que mistura usuários.

Por isso, um log must_understand=true é insuficiente. O registro deve apontar o status e sua referência, versão e teste que sustentam a capacidade, presença das duas diretivas, demais verificações, armazenamento efetivo e reutilização posterior.

Registro público não é certificado de software

A IANA mantém registros de diretivas de cache e códigos de status. Eles fornecem nomes estáveis e documentos definidores. São coordenadas comuns, não atestados de uma instalação.

Ver must-understand numa tabela não prova que um binário o implementou. Ver um status registrado não demonstra que o cache aplica suas regras. Um teste bem-sucedido para um código também não cobre automaticamente códigos futuros.

A capacidade precisa de um pequeno dossiê: versão do mecanismo e do módulo, definição usada, requisitos testados e resultados. A diretiva cria um ponto interoperável para consultar essa prova; não produz a prova.

O histórico do RFC 9111 explica que must-understand foi introduzido para que caches não precisem compreender a semântica de novos status, a menos que ele apareça. A origem pode sinalizar que as regras especiais importam. Não pode declarar um intermediário remoto competente.

O par não é privacidade

O RFC 9111 afirma que no-store não é mecanismo confiável ou suficiente de privacidade. Caches maliciosos ou comprometidos podem desobedecer, e redes podem ser interceptadas. A combinação não amplia essa promessa.

Ela tampouco decide autorização, isolamento entre usuários, confidencialidade no transporte ou proteção no disco. Transformar o cabeçalho num selo de classificação desviaria a atenção dos controles que realmente fornecem essas propriedades.

Esta pesquisa não testou fornecedores nem mediu adoção, incidentes ou vazamentos. Os percursos são hipóteses extraídas das especificações.

Fontes e limite da evidência

Registros e errata são retratos na data da pesquisa. As fontes estabelecem semântica e uma leitura de governança, não suporte universal dos produtos.