Resumo

  • A RFC 5861, de maio de 2010, saiu como documento informativo independente e definiu stale-while-revalidate para responder enquanto valida em segundo plano e stale-if-error para responder com cópia antiga diante de erro.
  • Os exemplos marcam janelas distintas. max-age=600, stale-while-revalidate=30 oferece dez minutos de frescor e até trinta segundos de margem; max-age=600, stale-if-error=1200 pode transformar um 500 aos 900 segundos em um 200 guardado com Age: 900.
  • A RFC 9111, de junho de 2022, manteve a exigência de permissão para respostas antigas e tornou obsoleto o campo Warning da regra anterior.

O documento velho chega primeiro

Um cache evita que cada leitor peça a mesma página à origem. Enquanto a cópia está fresca, a decisão é simples. Quando esse prazo vence, validá-la exige uma viagem de rede e tempo de servidor, mesmo que o conteúdo não tenha mudado. A RFC 5861 permitiu que o publicador autorizasse uma pequena resposta adiantada.

Com Cache-Control: max-age=600, stale-while-revalidate=30, a cópia é fresca por 600 segundos. Nos trinta seguintes, o cache pode enviá-la já antiga ao leitor e consultar a origem em segundo plano. A pessoa recebe a página sem esperar pela verificação. Se a origem confirmar a versão ou entregar outra, as próximas respostas podem refletir o resultado. A margem existe para ocultar latência, não para apagar o relógio.

Mesmo sem uma visita que dispare a validação, a janela termina. Se a consulta não concluir, a próxima requisição depois dos trinta segundos espera o tratamento normal. Uma página pouco acessada pode não receber benefício algum. O tamanho da margem e a frequência de tráfego determinam quantas respostas escapam da espera. Quem publica a página escolhe quanto atraso entre uma correção e a visão do leitor suporta.

Um erro escondido atrás de um sucesso anterior

stale-if-error entra em outra cena: o cache tenta obter uma resposta atual e encontra uma condição que geraria 500, 502, 503 ou 504. Dentro do limite escolhido, ele pode responder com a cópia antiga. O usuário recebe um êxito registrado antes da falha atual do servidor.

O exemplo da RFC começa com max-age=600, stale-if-error=1200. Aos 900 segundos de idade, a validação bate num 500. O cache pode devolver o corpo de um 200 OK guardado, acompanhado de Age: 900. O status do resultado entregue é 200; a idade revela a distância desde a geração ou validação na origem. A falha não desapareceu do funcionamento do servidor. Ela foi coberta, por tempo definido, no caminho até o leitor.

Os 1.200 segundos acrescentam-se aos 600 de frescor. Passados 1.800 segundos de idade total no exemplo, o erro atravessa o cache. Para uma página de referência, vinte minutos de atraso talvez sejam um preço aceitável para resistir a uma pane. Para um saldo, uma permissão ou instrução de pagamento, um valor antigo pode causar dano próprio. O prazo precisa refletir o conteúdo, não apenas a vontade de manter gráficos de disponibilidade bonitos.

As duas extensões têm gatilhos e funções diferentes. Uma lida com verificação lenta enquanto a cópia é servida. A outra cobre uma tentativa que falhou. Misturá-las em uma opção genérica de “aceitar dados velhos” esconderia quanto tempo foi autorizado e qual problema operacional justificou a escolha. O cache exerce uma liberdade delimitada pelo publicador.

A etiqueta Warning saiu de cena

O texto de 2010 esperava Age maior que zero e o campo Warning nas respostas antigas, de acordo com o HTTP da época. Em 2022, a RFC 9111 tornou Warning obsoleto: ele era pouco gerado e raramente aparecia ao usuário. Age continua dando uma estimativa do tempo desde a origem ou da última validação. Olhar só para o 200 não revela que a resposta veio de armazenamento; esperar pela velha etiqueta tampouco é uma boa leitura da regra atual.

A especificação de 2022 também impede o cache de enviar cópia velha quando no-cache, must-revalidate e outras ordens aplicáveis proíbem isso. Nos demais casos precisa de desconexão, permissão expressa de cliente ou origem, ou acordo fora do protocolo. As extensões de 2010 aparecem como exemplos dessa permissão. O intermediário não pode decretar sozinho a validade de toda página que guarda.

A RFC 5861 foi uma publicação informativa independente; a RFC 9111 é a norma de cache de 2022 que a cita no quadro das permissões. Respostas e configurações datadas, inclusive durante panes, mostrariam onde a prática ocorreu. O registro normativo já explica a escolha: a origem concede uma idade extra, o cache compra velocidade ou continuidade com ela, e o leitor recebe uma versão anterior dos fatos.