Résumé

  • Retry-After indique quand un agent utilisateur devrait réessayer, pas quand le rétablissement est garanti.
  • La valeur peut être une date HTTP absolue ou un délai en secondes ; l’horloge et l’interprétation font donc partie de la preuve.
  • Un 503 ou un 429 décrit la réponse observée, sans révéler la capacité future ni l’état de toutes les dépendances.
  • Un relevé de décision de nouvelle tentative doit relier l’instruction, des données récentes sur l’état du service et le résultat effectivement obtenu.

Imaginons un contrôleur de reprise qui reçoit 503 Service Unavailable avec Retry-After: 120. Il retient toutes les requêtes, place un repère vert deux minutes plus tard et libère toute la file à la même seconde. L’incident est déclaré clos avant qu’une seule nouvelle requête n’ait réussi. À l’échéance, le serveur d’origine reste surchargé, une dépendance est indisponible et la vague synchronisée prolonge la surcharge.

L’en-tête était valide. La conclusion de rétablissement ne l’était pas.

RFC 9110 donne à Retry-After un sens précis : indiquer combien de temps l’agent utilisateur devrait attendre avant une requête de suivi. Avec 503, le serveur peut suggérer un moment approprié pour réessayer. Dans une réponse de redirection, le champ peut indiquer le délai qu’il conviendrait d’observer avant de suivre la nouvelle adresse. Aucun de ces usages ne transforme l’heure annoncée en prévision de santé.

Le champ accepte deux formes. Une date HTTP désigne un instant ; un délai représente un nombre non négatif de secondes après réception. La première dépend des horloges, la seconde de l’heure réelle de réception et du traitement par les intermédiaires, files et minuteries. Ne conserver que l’échéance calculée efface l’instruction originale.

Le code d’état a lui aussi une limite. RFC 9110 décrit 503 comme une incapacité temporaire due à une surcharge ou à une maintenance planifiée. Le serveur peut proposer un délai, mais il ne garantit pas que la contrainte disparaîtra exactement alors. La spécification n’oblige d’ailleurs pas un serveur surchargé à répondre systématiquement par 503. La reprise peut être partielle, régionale, liée au contexte d’accès ou bloquée ailleurs.

RFC 6585 définit 429 Too Many Requests. La réponse peut porter Retry-After, mais la manière de compter les requêtes et d’identifier l’utilisateur reste volontairement propre au serveur. Un jeton, compte, tenant, chemin ou point de présence peut relever d’une limite différente. Un délai sans ce périmètre ne prouve pas que la prochaine requête sera admise.

La provenance importe également. La réponse peut venir de l’origine, d’une passerelle, d’un proxy, d’un CDN ou d’un gestionnaire d’API. Elle prouve que ce composant a donné cette instruction pour cet échange, non que toutes les couches partagent le même état.

Le relevé de décision de nouvelle tentative doit garder la requête et la réponse initiales, le point d’observation, le code, la valeur brute, sa forme, l’heure de réception, l’instant calculé, la source d’horloge et l’âge ajouté par un intermédiaire. Il y joint le périmètre de limitation sans conserver de secret.

Il enregistre ensuite la stratégie de temporisation, la gigue, le budget de tentatives, la limite de requêtes simultanées, l’annulation et l’heure d’envoi. Juste avant de laisser partir la requête, il ajoute des contrôles récents sur le fonctionnement, la capacité disponible, les dépendances et l’autorisation. Enfin, il conserve la réponse obtenue et le résultat de la transaction.

Le tableau de bord peut alors distinguer « tentative autorisée après le délai », « santé vérifiée », « requête admise » et « transaction terminée ». Ces événements sont liés ; aucun ne crée automatiquement le suivant.

Sources

RFC 9110 — HTTP Semantics; RFC 6585 — Additional HTTP Status Codes.