Cache HTTP sem fugas: classificar respostas antes de escolher diretivas

Armazenar, reutilizar e validar são decisões diferentes

Uma cache pode armazenar uma resposta e ainda precisar de consultar a origem antes de a reutilizar. Frescura permite reutilização sem validação durante uma janela; stale não significa automaticamente inutilizável, porque pedidos, diretivas e ligação à origem alteram o resultado.

Autorização e cache precisam de composição cuidadosa. Respostas a pedidos com Authorization têm restrições de armazenamento partilhado salvo diretivas que o permitam. Mesmo quando o objeto está em cache, a aplicação não deve assumir que a autorização anterior continua válida.

Uma matriz explícita evita defaults contraditórios

Defina a política no nível da resposta, não numa configuração global. Garanta que a CDN não substitui headers da origem sem decisão consciente. Teste headers finais no edge, porque comportamento correto na aplicação pode ser alterado por proxy.

Testar com duas identidades e três camadas

Execute a mesma rota como anónimo, utilizador A e utilizador B através de browser, CDN e origem. Compare Age, Cache-Control, Vary, ETag, status, corpo e headers sensíveis. Mude os dados e a autorização entre pedidos.

Inclua cold, fresh, revalidated, stale, origem indisponível, purge e deploy. Observe cache hit por classe sem registar cookies, tokens ou respostas pessoais em telemetria.

• Não colocar Set-Cookie ou dados de sessão numa resposta partilhável sem análise explícita.
• Evitar Vary: Cookie indiscriminado; separar rotas ou chaves quando possível.
• Usar URLs versionados para assets e TTL curto/validação para documentos mutáveis.
• Monitorizar hit ratio por classe, respostas 304, objetos stale, purge e incidentes de separação.