Résumé

  • RFC 5861, publié en mai 2010 comme contribution indépendante informative, décrit stale-while-revalidate et stale-if-error : servir brièvement l’ancien contenu pendant une vérification, ou le servir lorsqu’une erreur du serveur devrait apparaître.
  • Ses exemples séparent les comptes. max-age=600, stale-while-revalidate=30 autorise dix minutes de fraîcheur puis trente secondes de grâce ; max-age=600, stale-if-error=1200 peut remplacer une erreur 500 à l’âge de 900 secondes par un ancien 200 portant Age: 900.
  • RFC 9111, de juin 2022, maintient l’exigence d’une permission pour servir une réponse périmée et retire le champ Warning des règles modernes de mise en cache.

Le vieux document arrive avant la réponse de l’origine

Un cache garde une copie pour éviter de demander sans cesse la même ressource au serveur. Pendant sa durée de fraîcheur, la copie sert directement. Une fois cette durée passée, il faut normalement vérifier si l’origine possède une version nouvelle. Cette vérification prend du temps, même lorsque le document n’a pas changé. Un lecteur peut attendre un aller-retour réseau pour une réponse déjà présente tout près de lui.

RFC 5861 a autorisé l’origine à allouer une petite rallonge. Avec Cache-Control: max-age=600, stale-while-revalidate=30, la copie reste fraîche 600 secondes. Durant les 30 secondes suivantes, le cache peut envoyer immédiatement cette copie devenue périmée et lancer en arrière-plan sa vérification. La réponse rapide ne prétend pas que le contrôle est terminé. Le cache travaille sur deux fronts : répondre au visiteur et demander au serveur si l’ancienne version tient encore.

La fenêtre s’achève même si personne n’est venu déclencher une vérification. Si le contrôle reste sans résultat, la requête suivante attend le traitement normal après ces 30 secondes. Une page rarement visitée peut donc ne jamais profiter de l’astuce. La taille de la rallonge et la densité du trafic déterminent la fréquence des réponses instantanées. L’éditeur du contenu choisit combien de retard dans l’apparition de ses corrections il peut accepter.

Une panne masquée par une réussite passée

stale-if-error s’applique à une autre situation. Le cache tente d’obtenir une réponse actuelle et rencontre une défaillance qui produirait 500, 502, 503 ou 504. Dans une limite fixée en secondes, il peut servir son ancienne copie. Le visiteur reçoit alors une réponse issue d’un moment où le serveur fonctionnait, plutôt que la panne qui vient de se produire.

L’exemple de RFC 5861 est précis : une réponse portant max-age=600, stale-if-error=1200 reste fraîche dix minutes. À l’âge de 900 secondes, une validation échoue avec un 500. Le cache peut renvoyer la copie enregistrée, avec le statut 200 OK et Age: 900. Le 200 décrit le contenu livré par le cache ; l’Age révèle son ancienneté. Le serveur d’origine a bien rencontré une erreur pendant la tentative de rafraîchissement.

Les 1 200 secondes s’ajoutent aux 600 secondes de fraîcheur. Quand l’âge total dépasse 1 800 secondes dans cet exemple, l’erreur doit passer au lecteur. Le cache a un crédit de temps, pas une réserve inépuisable de succès anciens. Pour certaines pages, vingt minutes de continuité valent mieux qu’une panne ; pour une instruction de paiement ou une permission qui change vite, une ancienne réponse peut coûter plus cher que l’attente.

Les deux extensions règlent donc deux problèmes distincts. La première cache la latence d’une vérification possible. La seconde couvre une erreur effective. L’origine peut définir des durées différentes parce que les conséquences diffèrent : un contrôle lent et une panne ne sont pas le même risque. Le cache conserve une marge de décision à l’intérieur des durées publiées.

Le vieux panneau « Warning » a disparu

En 2010, RFC 5861 attendait qu’une réponse périmée porte un Age non nul et un champ Warning, conformément aux règles de l’époque. RFC 9111 a supprimé Warning en 2022 : le texte constate que ce champ était peu produit et peu montré aux lecteurs. D’autres en-têtes, notamment Age, permettent de lire l’ancienneté de la copie. Chercher systématiquement Warning dans une réponse actuelle revient à chercher un panneau retiré du protocole.

Le même RFC de 2022 maintient une frontière ferme. Un cache ne peut servir une réponse périmée quand no-cache, must-revalidate ou une autre instruction applicable l’interdit. En l’absence d’un tel interdit, il lui faut une condition reconnue : déconnexion, permission explicite du client ou de l’origine comme les extensions de RFC 5861, ou accord hors protocole. La rapidité n’est pas une autorisation générale de recycler n’importe quelle réponse stockée.

RFC 5861 était une publication informative indépendante, et RFC 9111 est devenu un standard HTTP de 2022 qui cite ces extensions parmi les permissions explicites. Cette chronologie montre la place acquise par la règle. Pour compter les déploiements, il manque des en-têtes conservés, des configurations de cache et des captures prises pendant une panne. Le dossier normatif montre déjà le compromis : l’origine autorise une durée d’ancienne vérité, le cache l’utilise et le lecteur en assume les effets.