Résumé

  • Cache-Control: only-if-cached demande uniquement une réponse stockée; un cache qui respecte la directive doit fournir une réponse admissible ou un 504.
  • Ce 504 peut être généré sans contacter l’origine: il prouve l’échec de la recherche dans le cache, pas l’indisponibilité du serveur d’origine.

Imaginons une sonde de disponibilité, dans un scénario explicitement hypothétique. L’opérateur veut savoir si une configuration se trouve déjà en périphérie et envoie donc un GET avec Cache-Control: only-if-cached. Le cache ne trouve aucune réponse stockée compatible et renvoie 504. Une règle d’alerte ne regarde que le code, conclut à un délai dépassé côté origine et réveille l’équipe correspondante. Pourtant, le cache a exécuté la consigne: aucun transfert et aucun appel à l’origine.

L’ambiguïté vient du double contexte du 504. La RFC 9110 définit généralement Gateway Timeout comme l’absence de réponse amont reçue à temps par une passerelle ou un proxy. La RFC 9111 donne au cache qui honore only-if-cached deux issues: une réponse stockée conforme aux autres contraintes de la requête, ou 504. Dans ce second cas, le client a précisément demandé qu’aucune récupération amont ne soit tentée.

La directive modifie donc l’expérience. Elle ne demande pas si l’origine sait répondre, mais si ce cache peut répondre avec un élément stocké qu’il a le droit de réutiliser. Lire le résultat comme celui d’une sonde de bout en bout confond deux chemins de contrôle.

La présence de données ne suffit pas. La cible et la méthode doivent correspondre; les champs nommés par Vary doivent coïncider; les obligations de validation doivent être respectées; la réponse doit être fraîche, validée ou autorisée à être servie périmée. Un cache peut détenir des octets pour l’URI sans posséder de réponse admissible. Le 504 peut donc signifier «rien d’utilisable ici avec ces contraintes», et non «rien n’est stocké».

Le code n’identifie pas non plus le cache qui décide. Une requête peut traverser un cache de navigateur, un proxy d’entreprise, un CDN et une passerelle. Il faut connaître le cache répondant, la directive observée à ce point, les candidats trouvés et la décision de ne pas transférer. Sans cette trace, le tableau de bord assigne une cause par habitude.

Les conséquences opérationnelles sont concrètes. Une panne de l’origine et l’absence d’une copie admissible dans le cache n’ont ni le même propriétaire ni le même remède. Une sonde ordinaire qui réussit à côté d’une sonde limitée au cache ne révèle pas forcément une intermittence : les deux requêtes posent des questions différentes.

Conservez un reçu de décision limité au cache. Il s’agit d’un contrôle éditorial proposé ici, pas d’un objet de protocole défini par l’IETF. Reliez cible, méthode, directives, identité et clé du cache, candidats, comparaison Vary, fraîcheur ou permission de servir du périmé, validation, réponse choisie ou échec, décision de transfert et trace de tentative amont. Classez ensuite l’événement comme éligibilité du cache, politique de transfert ou délai amont.

L’absence d’appel amont ne prouve pas que l’origine était saine ; elle prouve que cette observation ne peut établir sa panne. Une sonde distincte, sans contrainte limitée au cache, doit tester l’origine. Le contexte de requête et la trace d’exécution, pas le code isolé, fondent l’attribution.

Sources