Resumo

  • A RFC 9111 exige que o cache que recebe uma resposta sem erro a uma requisição não segura invalide o URI-alvo, mas a regra atua nos caches pelos quais a requisição passou.
  • Uma alegação de limpeza global precisa de evidência separada sobre cobertura de caminhos, URIs relacionados e chaves derivadas pela aplicação.

Considere um incidente expressamente hipotético. Um cliente envia um PUT, a origem responde 204 No Content e o painel anuncia que a limpeza global terminou. A gravação atravessou um cache de aplicação e um gateway regional. Ainda assim, uma borda fora desse caminho continua entregando uma coleção montada com o objeto antigo. O status 204 não identifica essa borda nem a chave derivada que sustenta a coleção.

Isso não é uma falha do HTTP. É o limite entre uma regra de protocolo e uma afirmação operacional. A RFC 9110 chama de seguro o método cuja semântica definida é essencialmente de leitura; GET, HEAD, OPTIONS e TRACE são seguros. Métodos capazes de alterar estado recebem outro tratamento. Pela RFC 9111, o cache deve encaminhar uma requisição não segura até a origem: não pode gerar a resposta antes de encaminhar a requisição e receber a resposta correspondente.

A resposta cria uma obrigação específica. Quando um cache recebe uma resposta sem erro a um método não seguro, deve invalidar o URI-alvo. Nesse contexto, sem erro significa um status 2xx ou 3xx. Invalidar pode remover respostas armazenadas correspondentes ou marcá-las como inválidas, exigindo validação antes de um novo uso. A regra impede o reaproveitamento sem nova verificação; não declara que todas as cópias do sistema desapareceram.

A RFC 9111 também permite invalidar outros URIs. Location e Content-Location podem fornecer candidatos quando têm a mesma origem do URI-alvo. A permissão é útil, mas não constitui descoberta universal de dependências. Um cache não deve invalidar por essa regra um candidato de outra origem, nem precisa deduzir todas as páginas de produto, listas, buscas, chaves substitutas ou partes pré-computadas que a aplicação derivou do objeto alterado.

A topologia impõe um segundo limite. A especificação diz expressamente que o mecanismo não garante invalidação global: a requisição que muda o estado invalida respostas somente nos caches que atravessa. Um cache presente apenas em outro caminho de leitura não recebeu o evento de protocolo que acionaria sua obrigação local. Multi-CDN, desvios do shield, partições regionais e caminhos distintos para API e páginas transformam essa precisão em um problema de controle.

Três afirmações acabam indevidamente fundidas. “A origem aceitou a gravação” descreve a resposta. “Um cache atravessado invalidou o URI-alvo” descreve uma ação local exigida. “Todo leitor verá o novo estado” depende de topologia, derivação de chaves e verificação. A primeira não demonstra a segunda em cada camada, e nenhuma das duas basta para sustentar a terceira.

O intervalo pode ser fechado com um recibo do caminho de invalidação. Trata-se de uma síntese editorial de controle proposta aqui, não de um objeto definido pelo IETF. O recibo vincula a requisição não segura e a resposta às instâncias de cache que as transportaram; registra o URI-alvo normalizado e a ação local; distingue a invalidação obrigatória do alvo do tratamento opcional de Location ou Content-Location; anexa o mapa de coleções, buscas, fragmentos e chaves substitutas; e guarda sondagens sem cache em cada rota de entrega relevante.

Depois de uma gravação, a pergunta deixa de ser se o 204 limpou o mundo. Passa a ser: qual caminho transportou a mudança, qual cache agiu, quais identidades foram cobertas e quais leituras independentes demonstraram o novo estado? É assim que uma ação local em conformidade com o protocolo se transforma em evidência para uma afirmação sistêmica.

Fontes