Resumo

  • Cache-Groups cria uma relação apenas entre respostas da mesma origem, guardadas no mesmo cache e marcadas com a mesma string exata e sensível a maiúsculas.
  • Cache-Group-Invalidation oferece uma decisão local e opcional após uma requisição insegura; não há cascata nem sincronização entre caches.

Atualizar um registro de catálogo pode afetar a página do item, uma lista e um agregado. As chaves de cache continuam distintas. RFC 9875 introduz uma forma de declarar que essas respostas armazenadas estão relacionadas, sem transformá-las em uma única representação.

O campo Cache-Groups é uma List de Strings de Structured Fields. A string é opaca: o cache compara, mas não interpreta uma hierarquia ou semântica empresarial. A ordem não importa e parâmetros desconhecidos são ignorados. A implementação deve suportar pelo menos 32 grupos em um campo e 32 caracteres em cada membro, respeitando os limites gerais dos campos HTTP.

O grupo só existe quando três condições coincidem. As respostas precisam estar no mesmo cache, trazer exatamente a mesma string — inclusive maiúsculas e minúsculas — e compartilhar a mesma origem URI. Uma string igual em outra origem não participa. A mesma string guardada em outro cache também não produz estado comum.

O segundo campo, Cache-Group-Invalidation, pode aparecer na resposta a uma requisição capaz de mudar estado, como POST, PUT ou DELETE. Ele lista grupos que o cache receptor pode invalidar. Se estiver na resposta a um método seguro, como GET, deve ser ignorado. O método faz parte da evidência e não pode desaparecer do recibo.

O verbo normativo é MAY. Um cache pode ampliar a invalidação para membros relacionados e pode agir sobre o sinal, mas o RFC 9875 não obriga todos os intermediários a uma execução uniforme. O RFC 9213 permite direcionar controles a classes de caches e pode fortalecer a regra. Essa política adicional precisa ser identificada e auditada separadamente.

Invalidar também não significa necessariamente apagar. Pelo RFC 9111, o cache pode remover as respostas armazenadas ou marcá-las como inválidas, exigindo validação antes do próximo uso. Um evento local não informa se os bytes ficaram, se a validação posterior passou ou se uma representação diferente foi preenchida.

Não há expansão transitiva. Se A compartilha um grupo com B, e B compartilha outro com C, a invalidação de A pelo primeiro grupo não atravessa B para alcançar C. O mecanismo não entra em cascata. A lista efetiva depende do inventário que aquele cache mantinha no momento do processamento.

A fronteira mais importante é a topologia. O RFC limita o mecanismo a um único cache e a uma única origem. Não sincroniza caches em hierarquia ou malha e não associa respostas de origens diferentes. Um ponto de presença pode receber o sinal enquanto outro caminho nunca o observa.

Por isso, o controle deve produzir uma cadeia: mudança no origin; autoridade para emitir os campos; método e resposta; recebimento por intermediário; suporte e versão; política local; membros existentes; decisão tomada; remoção ou marca; validação ou novo preenchimento; canário da aplicação em cada caminho material. Uma camada não serve como recibo da próxima.

Em hospedagem compartilhada, a autoridade do cabeçalho é crítica. O RFC alerta que uma parte pode agrupar seus recursos com os de outra parte na mesma origem ou emitir sinais com efeitos sobre ela. A plataforma precisa limitar a emissão e a preservação dos campos por tenant e origem.

O registro de campos HTTP da IANA apresenta ambos como Lists permanentes. O registro prova nome e referência comuns, não implementação, encaminhamento, processamento ou resultado em produção.

Fontes