O que é o cabeçalho Cache-Control?

Cache-Control é um cabeçalho de requisição ou resposta HTTP cujas diretivas regem o armazenamento, a validade, a revalidação e a reutilização por caches. Diretivas diferentes podem se aplicar a navegadores e intermediários compartilhados.

Cache-Control comunica a política por meio de diretivas separadas por vírgulas, anexadas a uma requisição ou resposta HTTP. As diretivas de validade determinam quando a reutilização pode ocorrer sem consultar a origem, enquanto as diretivas de armazenamento, validação e escopo restringem o que caches privados e compartilhados podem reter ou servir. As diretivas de resposta são obrigatórias para um cache em conformidade, enquanto as diretivas de requisição são orientativas, e uma CDN pode ignorar aquelas que permitiriam a um cliente forçar uma consulta à origem: o Google Cloud CDN, por exemplo, ignora no-cache e max-age nas requisições. O cabeçalho se dirige a todos os caches no caminho ao mesmo tempo e não pode se dirigir a um cache específico, por isso a RFC 9213 define CDN-Cache-Control, um cabeçalho de resposta separado com as mesmas diretivas, que um cache de CDN compatível usa no lugar de Cache-Control.

no-cache permite que uma resposta seja armazenada, mas exige validação bem-sucedida com a origem antes de cada reutilização; no-store instrui todos os caches, privados ou compartilhados, a não armazenar a resposta de forma alguma. A RFC 9111 acrescenta que no-store não é um mecanismo confiável nem suficiente para garantir a privacidade, portanto é uma instrução de cache e não um substituto para o controle de acesso.
max-age define o prazo de validade para todos os caches; s-maxage o substitui em caches compartilhados, como CDNs, e é ignorado pelos navegadores. Para um arquivo cuja URL muda sempre que seu conteúdo muda, o padrão da MDN é usar max-age com um prazo longo (o exemplo é de um ano) junto com immutable, que indica que a resposta não será atualizada enquanto estiver válida. s-maxage também incorpora o significado de proxy-revalidate: quando a resposta expira, um cache compartilhado deve revalidá-la antes de reutilizá-la. Com Origin Cache Control habilitado, que é o padrão nos planos Free, Pro e Business da Cloudflare, a Cloudflare não serve uma resposta expirada com s-maxage, e o Google Cloud CDN documenta o mesmo comportamento, portanto stale-while-revalidate não tem efeito junto dessa diretiva nesses provedores. A alternativa documentada pela Cloudflare é usar max-age com stale-while-revalidate e uma regra separada de TTL nos nós de borda.
private impede o armazenamento por caches compartilhados, mas permite o cache do próprio navegador, portanto é diferente de desabilitar o armazenamento em cache. Essa diretiva precisa ser definida deliberadamente em respostas personalizadas. Por padrão, o HTTP impede o armazenamento de uma resposta em caches compartilhados apenas quando a requisição contém um cabeçalho Authorization e, mesmo nesse caso, public, s-maxage ou must-revalidate elimina essa restrição. Uma sessão enviada em um cabeçalho de requisição Cookie não aciona nenhuma regra desse tipo, e a RFC 9111 afirma que um cabeçalho de resposta Set-Cookie não impede o armazenamento em cache. O Google Cloud CDN não armazena em cache uma resposta que contém Set-Cookie. A Cloudflare, em seu nível de cache padrão, também não a armazena enquanto Origin Cache Control está habilitado, mas, com esse recurso desabilitado, pode armazenar a resposta em cache após remover o cabeçalho Set-Cookie. Em ambos os casos, trata-se de um comportamento do provedor, não de uma regra do HTTP.
Uma resposta sem Cache-Control ainda pode ser armazenada em cache. A RFC 9111 permite que um cache atribua um tempo de validade heurístico a uma resposta que admite armazenamento heurístico em cache e não tem expiração explícita, sugerindo no máximo uma fração do tempo decorrido desde Last-Modified, e as CDNs aplicam seu próprio tempo de validade padrão quando a origem não envia nenhum. Os erros seguem as mesmas regras: uma resposta final com validade explícita pode ser armazenada, portanto uma resposta 5xx enviada com o longo max-age usado para respostas bem-sucedidas pode ser armazenada e servida novamente por um cache posterior, embora os códigos de status armazenados por cada CDN dependam do provedor. Envie no-store em tudo que não deve ser armazenado em cache e não atribua às respostas de erro os tempos de validade usados nas respostas bem-sucedidas. Uma CDN também pode armazenar erros em cache por uma configuração própria que o cabeçalho não desativa: o Amazon CloudFront ignora no-store, no-cache e private em respostas 500, 502, 503 e 504 e as armazena em cache pelo período definido em Error Caching Minimum TTL, que é configurado por código de status e tem como padrão 10 segundos. Ele não armazena esses erros em cache quando o comportamento de cache usa a política de cache gerenciada CachingDisabled.
O cabeçalho da origem nem sempre tem a palavra final na borda. O Amazon CloudFront usa o TTL mínimo da política de cache quando ele é maior que 0, mesmo que a origem tenha enviado no-cache, no-store ou private. Uma regra Edge Cache TTL da Cloudflare substitui s-maxage e as diretivas de revalidação, e o modo FORCE_CACHE_ALL do Google Cloud CDN armazena respostas bem-sucedidas em cache independentemente das diretivas da origem. Confira as configurações de TTL e de substituição da CDN antes de confiar em uma diretiva para manter uma resposta fora de um cache compartilhado.

Defina Cache-Control conforme a resposta seja pública, privada, imutável ou atualizada com frequência. Diretivas conflitantes ou permissivas demais podem expor dados privados ou preservar mídia desatualizada.

Quando a Transloadit serve um arquivo transformado pelo Smart CDN, o Robot /file/serve define o cabeçalho Cache-Control do resultado, com um tempo de validade para o navegador em max-age e outro para o cache compartilhado em s-maxage. O parâmetro cache_duration do Robot define ambas as diretivas com um único valor, e o parâmetro headers mescla seus próprios valores de cabeçalho aos padrões, dando preferência aos seus valores. Para URLs assinadas do Smart CDN, o tempo de validade efetivo do cache também é limitado pelo tempo de validade restante da assinatura.

A página do Robot lista os tempos de validade padrão atuais.

Explore os recursos de entrega da Transloadit

O que é o cabeçalho Cache-Control?

Como funciona o cabeçalho Cache-Control

Informações essenciais

Quando o cabeçalho Cache-Control é importante

Como a Transloadit ajuda com o cabeçalho Cache-Control

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional