Resumo

  • Cache-Groups permite que uma resposta declare uma ou mais strings opacas e sensíveis a maiúsculas e minúsculas.
  • A associação vale somente no mesmo cache e na mesma origem URI.
  • Cache-Group-Invalidation em uma resposta a uma requisição segura deve ser ignorado; em uma requisição insegura, pode invalidar respostas armazenadas que compartilhem os grupos nomeados.
  • A invalidação é opcional, salvo se outra extensão a tornar mais forte, e não percorre grupos relacionados posteriormente.

A RFC 9875 oferece ao cache uma maneira de reconhecer respostas relacionadas. O produtor de uma resposta pode declarar grupos, e o cache pode usar esses nomes para localizar representações armazenadas no mesmo escopo. Os identificadores são opacos e diferenciam maiúsculas de minúsculas. Isso deixa claro que o protocolo não fornece uma taxonomia universal nem decide quem controla cada grupo. A política de nomes, a propriedade do espaço e a autoridade de invalidação continuam sendo decisões de arquitetura.

O limite do cache deve ser tratado como uma fronteira real. Um grupo visto por um cache não se transforma em estado compartilhado em outro cache. Intermediários diferentes podem ter armazenamentos independentes, e a RFC não cria uma relação entre respostas de origens diferentes. Portanto, não se deve descrever o mecanismo como sincronização entre caches, entre CDNs ou entre origens. Uma invalidação observada localmente não demonstra que um segundo cache recebeu ou aplicou a mesma informação.

Há uma diferença importante entre tratamento obrigatório e comportamento opcional. Quando o campo Cache-Group-Invalidation aparece em uma resposta a uma requisição segura, ele deve ser ignorado. Essa é uma regra de processamento. Quando aparece em uma requisição insegura, o cache pode invalidar respostas armazenadas que compartilham os grupos indicados. O verbo pode é decisivo: sem uma extensão que reforce a regra, a invalidação não é obrigatória. Também não há uma cascata automática por grupos que passem a se relacionar depois.

A primeira falha possível é a permanência de conteúdo desatualizado depois de uma mudança de estado. A segunda é o excesso de alcance: um nome de grupo amplo pode incluir conteúdo de outro inquilino. Em hospedagem com origem compartilhada, uma parte poderia se associar aos recursos de outra ou invalidá-los se o operador não controlar acesso e emissão. Nomes opacos não impedem esse abuso por si só; eles precisam estar ligados a autorização e inventário.

A decisão não é tratar um cabeçalho como um botão de limpeza global. É definir o cache e a origem em que a associação tem sentido, além de separar a autoridade que produz a resposta daquela que pode invalidar grupos. Se o objetivo for coordenar vários caches, o projeto precisa de outro mecanismo. Prometer mais do que o limite local cria uma dependência operacional que a especificação não sustenta.

Fontes