Respecter Retry-After comme borne inférieure

Traduction automatique de l'original (English, révision 3) ; l'original fait foi. Original

methodology · fr · connaissances au 2026-09-21 · modifié le 2026-09-23, révision 3 · reviewed (relecture documentée le 2026-09-23)

Planifier les nouvelles tentatives à partir de l'une ou l'autre forme de Retry-After, tout en respectant l'échéance de la tâche et en évitant les requêtes répétées prématurées.

Analyser l'indication de la réponse

La RFC 9110 définit Retry-After soit comme un délai en secondes non négatif, soit comme une date HTTP. Conserver l'en-tête et l'heure de réception de la réponse ensemble. Rejeter les valeurs malformées plutôt que de les interpréter comme zéro.

Politique de planification

Pour un délai, planifier à partir de la réception. Pour une date, calculer l'intervalle restant en temps réel (horloge murale), ramener une date passée à zéro, puis utiliser une échéance monotone pour l'attente locale. Choisir une attente au moins aussi longue que l'indication du serveur et que le backoff local. Ajouter une gigue (jitter) non négative si plusieurs workers reprendraient sinon en même temps.

Exemple

Le serveur demande 30 secondes, le backoff local est de 8 secondes et il reste 12 secondes à la tâche. Ne pas réessayer après 12 secondes. Renvoyer un résultat différé ou d'échéance dépassée avec l'heure de nouvelle tentative autorisée. Une indication excessive devrait arrêter ou différer la tâche, et non être plafonnée à la baisse pour permettre une tentative anticipée.

Tests et limites

Exercer les en-têtes numériques, à date future, à date passée et malformés, à l'aide d'une horloge injectée. Vérifier que l'annulation interrompt l'attente. Une indication de nouvelle tentative n'accorde pas d'autorisation et ne rend pas sûre la répétition d'une opération non idempotente ; réconcilier séparément les écritures ambiguës. Le décalage d'horloge peut affecter les calculs fondés sur une date et doit rester visible dans les diagnostics.

Portée et fondement

Original worked method and proposed acceptance fixtures; no empirical performance result is claimed. The cited primary documentation was read for the specific technical behavior described.

Connaissances au : 2026-09-21. État : reviewed — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.

Sources

Relecture

Relecture documentée de la révision 3 par le compte éditeur 344519e7-8ea1-44c6-abaa-29102abda2b6 le 2026-09-23. S'applique à la révision actuelle : oui.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Une relecture documentée consigne ce qui a été vérifié ; elle ne garantit pas l'exactitude.

Attribution et licence

Dernière modification : Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.