Résumé

  • Dans draft-ietf-httpapi-ratelimit-headers-11, t indique l’intervalle pendant lequel le client ne devrait pas consommer plus que le quota disponible r ; la fin de cet intervalle ne promet pas le retour du quota.
  • Une conduite sûre expire l’ancienne observation, introduit de l’aléa et obtient un nouveau reçu. Elle ne remplit pas automatiquement un seau local et ne transforme jamais un indice de débit en admission acquise.

À 14 h 02, une API a répondu avec r=120;t=60. Le planificateur a réparti les cent vingt unités sur la minute. Puis il a programmé, pour 14 h 03 exactement, le retour du compteur à sa capacité maximale.

À 14 h 03, dix mille instances du même logiciel ont tiré la même conclusion. La fenêtre était terminée ; chacune croyait retrouver son droit initial. Le serveur, passé entre-temps en régime adaptatif, a prolongé la contrainte. La minute qui devait marquer le retour à la normale a produit la pointe la plus brutale.

Le champ n’avait annoncé aucun remplissage. Le calendrier venait du client.

La révision 11 de RateLimit header fields for HTTP a été publiée le 23 mai 2026 par le groupe IETF HTTPAPI. C’est un Internet-Draft actif, destiné au Standards Track et valable jusqu’au 24 novembre 2026. Ce n’est ni un RFC, ni une mesure d’adoption, ni le témoignage d’un déploiement. Le texte propose toutefois une séparation utile entre description de politique, état courant et décision future.

La politique et son état courant ne sont pas le même objet

RateLimit-Policy décrit une politique nommée. Le quota q est obligatoire ; l’unité qu, la fenêtre w et la clé de partition pk peuvent la préciser. Le document prévoit initialement les requêtes, les octets de contenu et les requêtes simultanées. Même pour l’unité « requêtes », la consommation effective d’une requête reste propre à l’implémentation.

RateLimit communique au contraire une limite de service courante pour une politique et une partition particulières. r indique le quota disponible ; t décrit la fenêtre effective. La politique peut durer des mois alors que l’observation devient obsolète avant la requête suivante. Les enregistrer dans le même champ « quota » détruit cette différence de temporalité.

Plusieurs politiques peuvent agir en même temps. Une limite horaire et une limite quotidienne peuvent toutes deux contraindre une opération. Le serveur peut n’exposer que la plus proche de l’épuisement. L’absence d’une politique dans la réponse ne signifie donc pas qu’elle a disparu, pas plus qu’un chiffre positif ne révèle toute la fonction d’admission.

Il faut conserver la politique, l’unité, la partition, la date de réponse, q, w, r, t et le statut HTTP. Sans ce contexte, « 120 restantes » est une phrase sans sujet ni durée.

Une fenêtre effective n’est pas une date de reset

Le paramètre t est un nombre de secondes compatible avec la forme delay-seconds. Cette durée relative évite que le client et le serveur partagent une horloge exacte. Elle limite aussi les effets d’un timestamp absolu identique envoyé à une population entière.

Sa sémantique est négative et prudente : pendant cet intervalle, le client ne devrait pas utiliser davantage que r. Elle ne dit pas ce qui sera disponible ensuite. Le draft l’énonce explicitement : le client ne doit pas supposer que toute la capacité sera restaurée à l’expiration. Le serveur peut modifier arbitrairement r et t entre deux réponses, notamment en saturation ou avec une fenêtre glissante.

Cette règle empêche le client de transformer une observation en créance. Au terme de l’intervalle, l’ancienne valeur doit être considérée comme périmée. Une nouvelle requête bornée peut chercher une nouvelle observation. Elle n’est pas le premier élément d’une rafale préautorisée.

Un contrôleur robuste ajoute de la gigue, maintient ses propres plafonds de concurrence et augmente progressivement son débit. Il distingue « l’ancien frein peut être réévalué » de « le serveur a remis cent vingt unités à ma disposition ».

Le quota disponible n’est pas une réservation

Le document interdit une autre extrapolation : un r positif ne garantit pas le service des prochaines requêtes. Dans ses considérations de sécurité, il précise que les unités disponibles sont des indications et non des requêtes accordées ou un engagement de niveau de service.

La capacité peut avoir changé entre l’émission de la réponse et l’arrivée du prochain appel. Une autre politique peut devenir limitante. Le serveur peut détecter une attaque et réduire artificiellement les valeurs. La requête peut échouer pour authentification, autorisation ou validation, autant de sujets que le champ RateLimit ne gouverne pas.

Le contraire est également possible. Une requête peut être servie alors que r=0. La spécification ne force aucune corrélation entre les valeurs et le statut de réponse. Le chiffre décrit le contrôle communiqué par le serveur ; il n’est pas l’algorithme complet de décision.

La bonne terminologie opérationnelle est donc précise : une tâche est « compatible avec la dernière indication connue », puis « envoyée », puis « admise », puis « exécutée », puis « confirmée ». Passer directement de l’indication au succès supprime les reçus qui permettraient de comprendre un échec.

Retry-After et t se touchent sans se confondre

Une réponse de limitation peut aussi comporter Retry-After. Le projet recommande alors que cette indication ne pointe pas avant la fin de la fenêtre effective. Cela évite deux conseils manifestement contradictoires.

Mais Retry-After répond à la question du prochain essai, tandis que t borne la consommation du quota annoncé. Aucun des deux ne garantit l’admission à l’instant visé. Un système adaptatif peut rester chargé ; une autre politique peut s’appliquer ; l’autorisation peut avoir changé. Une tentative future reste une tentative.

Le planificateur doit garder la provenance de chaque temporisation. Une attente imposée par le serveur, une temporisation locale de sécurité, une reprise exponentielle et une fenêtre de quota ne sont pas quatre noms pour un même compteur. Elles ont des propriétaires et des conditions de sortie différentes.

La partition n’accorde aucune identité

Une clé pk peut représenter la partition de quota pertinente pour une requête. Le serveur peut partitionner par utilisateur, application, méthode, ressource ou combinaison. S’il documente l’algorithme, le client peut prévoir si un appel futur devrait puiser dans le même réservoir.

Cette utilité ne transforme pas la clé en identité authentifiée. Deux utilisateurs peuvent partager une partition ; une seule application peut en rencontrer plusieurs. Une clé peut rester stable alors que l’autorisation change. Le draft demande d’éviter les informations sensibles et souligne le risque d’usurpation lorsqu’une partition contient des éléments identifiants.

L’autorisation est explicitement hors périmètre. Être sous la limite n’accorde aucun accès. Être autorisé n’assure aucun quota. Une erreur 401 ou 403 peut même consommer une unité selon la politique du service. Il faut donc rapprocher les reçus sans fusionner leurs sens.

Les intermédiaires ajoutent des tentatives invisibles

Un proxy peut relayer, réessayer ou appliquer sa propre limite. Il ne devrait pas rendre la politique d’origine plus permissive. Il peut la rendre plus restrictive s’il comprend l’unité et impose effectivement sa propre règle.

Le service qui émet la politique demeure responsable de son application et libre de traiter une requête. L’intermédiaire ne doit pas se proclamer oracle de la décision finale. Il devrait généralement transmettre même s’il pense que l’appel sera refusé.

Un retry transparent peut consommer du quota sans apparaître dans le compteur local du client. Ce décalage n’est pas, à lui seul, la preuve d’un vol d’unités. Il révèle l’absence d’une chaîne de tentatives. Les identifiants de requête, numéros d’essai, décisions du proxy et réponses du service doivent être reliés avant toute conclusion.

Un nombre généreux peut devenir une attaque

Le texte montre qu’une grande valeur r associée à un t court peut inciter un algorithme simpliste à envoyer beaucoup plus vite que ne le suggère le rapport q/w de la politique. La signalisation destinée à réduire la pression devient alors un accélérateur.

Une valeur excessive peut provenir d’un intermédiaire hostile, d’une mauvaise configuration ou d’un changement légitime. Dans tous les cas, le client reste responsable de ses propres bornes : requêtes par seconde, concurrence, mémoire, coût et charge imposée aux dépendances.

Le contrôleur doit plafonner les entrées distantes, monter en charge progressivement et conserver un coupe-circuit local. Accepter un conseil n’est pas déléguer son obligation de prudence.

Les problèmes structurés ne sont pas des verdicts

La révision 11 propose des types de problème pour quota dépassé, dépassement temporaire et usage anormal. Ils donnent aux clients des catégories et des noms de politiques exploitables par machine.

Un type « usage anormal détecté » reste cependant l’assertion du service qui répond. Il ne prouve pas l’intention malveillante, l’identité de l’auteur ou la justesse du classificateur. Il peut déclencher un ralentissement réversible ou une revue. Il ne doit pas devenir automatiquement une sanction irrévocable.

RFC 9457 structure le message, RFC 6585 définit 429, RFC 9110 encadre les champs et les statuts, RFC 9651 fournit la syntaxe structurée. La précision syntaxique améliore le reçu ; elle n’augmente pas l’autorité de sa source.

Sources et limites

Le dossier gelé contient la révision 11, ses pages Datatracker, le mandat HTTPAPI et son travail sur la vie privée, les RFC 9110, 9651, 6585, 9457 et 9205 ainsi que les registres IANA pertinents. Il établit le projet de mécanisme et ses limites déclarées. Il ne prouve aucun déploiement, incident, fournisseur, niveau d’adoption, performance ou interopérabilité.

Sources