Resumo

  • Um cache que implementa campos direcionados escolhe o primeiro campo válido e não vazio de sua lista ordenada; um cache que não inclui esse campo como alvo não deve alterar seu comportamento por causa dele.
  • Assim, a mesma resposta pode ser armazenada, recusada ou governada por outro campo em saltos diferentes, mesmo quando CDN-Cache-Control está correto.

Considere uma implantação explicitamente hipotética. A origem envia Cache-Control: no-store e CDN-Cache-Control: max-age=600. O primeiro CDN reconhece o campo direcionado e guarda a resposta por dez minutos. Um cache corporativo adiante não inclui esse campo na lista e obedece a no-store. Outro CDN coloca um campo próprio do fornecedor antes de CDN-Cache-Control e seleciona a outra política. Ainda assim, o painel registra apenas “política de cache: 600 segundos”.

O cabeçalho não é falso. O painel apagou o processo de decisão que lhe dá significado.

A RFC 9213 define campos direcionados de controle de cache, cujo nome distinto identifica o cache ou a classe de caches pretendida. CDN-Cache-Control é o exemplo padronizado. Seu valor usa a semântica das diretivas de cache, enquanto a implementação mantém uma lista ordenada de alvos. Essa lista pode ser fixa, configurável ou gerada por requisição. Diante de vários campos reconhecidos, o cache seleciona o primeiro valor válido e não vazio na ordem da lista.

A seleção exclui outras fontes. Depois de escolher um campo direcionado, o cache usa esse valor para determinar a política da resposta e ignora Cache-Control e Expires nessa resposta. Se não houver campo válido e não vazio em sua lista, volta aos mecanismos HTTP comuns da RFC 9111. Dois caches conformes podem receber os mesmos bytes e decidir de modo diferente porque suas listas não são iguais.

O escopo importa tanto quanto a prioridade. Um campo fora da lista de alvos de um cache não pode mudar seu comportamento e deve ser encaminhado. Um cache que não é CDN pode ver CDN-Cache-Control sem aplicá-lo. Um CDN que o usa normalmente encaminha o campo para CDNs posteriores, mas a RFC 9213 permite removê-lo quando a propagação é indesejável. O que aparece em um ponto de observação não comprova o conjunto visto por todos os outros saltos.

A análise sintática cria outra fronteira. Campos direcionados são dicionários Structured Fields. Embora pareçam com Cache-Control, o tratamento de erros não é intercambiável. Campo vazio ou inválido é ignorado e pode ativar o fallback. Um painel que guarda a sequência de caracteres, mas não o resultado do analisador, pode atribuir uma decisão a um campo que o cache nunca aceitou.

O frescor também é relativo ao cache que selecionou a política. No exemplo da RFC 9213, um CDN pode considerar a resposta fresca por 3.600 segundos, outros caches compartilhados por 600 e os demais por 60. Após 1.800 segundos, ela está fresca no CDN e vencida em outros pontos. Não há contradição; há políticas aplicáveis diferentes. O erro é reduzi-las a um estado único para toda a cadeia.

Essa redução pode se tornar falha de segurança. A RFC 9213 alerta que múltiplas políticas podem causar confusão e reutilização involuntária de informação sensível. Um teste bem-sucedido na origem comprova que os campos foram emitidos, não quais caches os reconheceram, qual campo foi escolhido, se a análise passou, se houve remoção nem se a reutilização respeitou o limite desejado.

A unidade prática de evidência é um registro da decisão de cache em cada salto. Para cada cache relevante, vincule classe e identidade, lista ordenada, campos recebidos, resultado da análise, campo escolhido, diretivas efetivas, entradas de frescor, fallback, encaminhamento ou remoção e uma observação de armazenamento ou reutilização. Saltos desconhecidos devem continuar explícitos.

Esse registro é um controle operacional editorial, não um objeto definido pelo IETF. Ele impede que um campo válido vire uma afirmação sem prova sobre a cadeia inteira.

Fontes