Résumé

  • Le code 429 désigne un budget de requêtes épuisé selon une règle du serveur. Il ne signifie pas que la requête est mal formée et ne prouve ni l’identité d’une personne ni un abus.
  • RFC 6585 autorise un délai Retry-After, mais ce délai reste une indication. Il ne réserve aucune capacité et ne garantit pas que la prochaine tentative sera admise.
  • La norme rend le refus interopérable tout en laissant l’autorité réelle à découvert : l’opérateur choisit qui est compté, sur quelle étendue et à quel coût, et peut renoncer à répondre lorsque le refus lui-même épuise les ressources.

Une bonne requête au mauvais rang

Un client appelle un service autorisé. La syntaxe est correcte, la cible existe et l’identifiant est valable. Le service accepte cinquante appels puis rejette le suivant. Rien dans le cinquante et unième message n’est nécessairement inférieur aux autres. La différence vit dans une mémoire extérieure au message : un compteur a atteint la valeur que l’exploitant a décidé de protéger.

C’est ce cas que RFC 6585 a isolé en 2012 avec 429 Too Many Requests. Une erreur générique aurait obligé le client à deviner s’il devait réparer son contenu. Une indisponibilité 503 aurait décrit la capacité générale du service, même si d’autres comptes ou d’autres ressources continuaient à fonctionner. Le nouveau code pouvait dire plus précisément : ce flux, tel que le serveur l’attribue, a dépassé son budget actuel.

Le texte normalise pourtant moins qu’on pourrait le croire. La représentation devrait expliquer la condition et peut fournir Retry-After. En revanche, le RFC refuse de définir la manière d’identifier l’utilisateur et la façon de compter les requêtes. Le protocole partage un verdict ; il ne centralise pas la politique qui l’a produit.

L’utilisateur entre guillemets

Le mot « utilisateur » paraît simple jusqu’au moment où un équipement doit le reconnaître avant de dépenser ses ressources. Un compte authentifié, une clé d’API, un cookie de session, un locataire ou une adresse source peuvent chacun servir de sujet comptable. Les identifiants et le cookie cités par RFC 6585 ne sont que des exemples.

Une adresse IP est disponible tôt, mais son apparente simplicité déplace le risque. Une entreprise, un accès résidentiel derrière CGNAT ou un relais de confidentialité peut présenter une seule adresse pour de nombreuses personnes. Le compteur devient alors collectif sans que ses membres aient choisi de l’être. Un 429 adressé à ce groupe peut être conforme au protocole ; il ne démontre pas que chaque personne a consommé sa part.

Le compte authentifié améliore parfois l’alignement avec le contrat commercial, mais il ne devient pas une personne certaine. Des appareils partagent un compte, une clé circule entre processus et un secret peut être compromis. L’exploitant doit donc limiter l’autorité de son jugement à la preuve disponible. Un compteur par adresse autorise un refus par adresse, pas une accusation morale.

Une portée invisible derrière trois chiffres

RFC 6585 cite trois étendues possibles : une ressource, un serveur entier ou un ensemble de serveurs. Chacune change la signification pratique du même code.

Limiter une recherche coûteuse séparément permet de conserver l’accès au reste de l’application. Compter tout un serveur protège une réserve commune, mais une opération légère et un rapport lourd peuvent alors valoir la même unité. Une limite par locataire rapproche capacité et contrat, à condition que l’attribution soit fiable. Un compteur commun à plusieurs régions assure une politique unique au prix de décisions sur la cohérence, les partitions et la panne du service de comptage.

Même l’unité « requête » mérite une définition locale. Faut-il compter l’arrivée, l’authentification réussie, l’admission ou la réponse achevée ? Une redirection consomme-t-elle une nouvelle unité ? Un flux HTTP/2 annulé reste-t-il dans le total ? Une reprise effectuée par un intermédiaire appartient-elle au client ? Le statut n’impose aucune réponse, car ces faits appartiennent au système d’exploitation du service.

Un compteur erroné peut refuser du travail légitime tout en produisant un message 429 parfaitement valide. La conformité de la réponse n’est pas une preuve d’exactitude du registre.

Attendre n’achète pas une place

Retry-After peut contenir une date HTTP ou un nombre entier de secondes. Une date absolue suppose une référence temporelle utilisable ; un délai se mesure après réception. Dans les deux cas, le client apprend quand ne pas revenir trop tôt. Il n’obtient pas une réservation.

Au terme de l’attente, la demande collective peut encore être élevée. La règle peut avoir changé, le compte peut avoir perdu son autorisation et la ressource visée peut ne plus avoir le même état. Si tous les clients libèrent leur file à la seconde indiquée, la fenêtre de récupération devient un nouveau pic.

Un client robuste joint donc l’indication du serveur à sa propre discipline : nombre d’essais borné, dispersion temporelle, échéance métier et traitement adapté à la méthode. Une opération non idempotente ne devient pas répétable parce qu’un nombre de secondes s’est écoulé. Le temps n’apporte aucune preuve sur les effets d’un échange interrompu.

Une frontière différente de 503

Le code 503 décrit, selon RFC 9110, un serveur temporairement incapable de traiter la requête en raison d’une surcharge ou d’une maintenance. Le code 429 décrit le dépassement attribué au sujet qu’une politique de limitation a choisi. Les deux réponses peuvent proposer Retry-After, sans devenir équivalentes.

Cette séparation empêche qu’un seul locataire bloque nécessairement tous les autres. Elle empêche aussi, si elle est utilisée honnêtement, qu’une pénurie générale soit racontée comme une faute du client. Une plateforme peut subir simultanément une saturation globale et un dépassement individuel ; elle devrait retourner le statut qui explique la décision réellement appliquée.

Le chiffre ne doit pas servir à déplacer la responsabilité. Il doit localiser le contrôle.

Le prix d’une explication

Les considérations de sécurité de RFC 6585 décrivent une limite rarement visible dans les interfaces. Sous attaque ou face à un volume immense venant d’une même partie, répondre 429 à chaque message consomme encore des ressources. Le serveur n’est donc pas obligé d’émettre le code ; il peut interrompre des connexions ou agir autrement.

Avant le refus, il a peut-être déjà analysé la requête, réalisé des opérations cryptographiques, retrouvé un compte, interrogé un compteur distribué et préparé une réponse chiffrée. Une défense trop explicative peut financer le travail de l’attaquant. Rejeter plus tôt économise le calcul, mais réduit souvent la qualité de l’identité disponible et augmente les dommages collatéraux.

La bonne décision n’est ni le silence universel ni l’explication universelle. C’est l’action la plus étroite que les preuves et le budget présent permettent encore.

Un refus que le cache ne peut prolonger

RFC 6585 interdit le stockage d’une réponse 429 par un cache. Le verdict dépend d’un instant, d’un sujet attribué, d’une étendue et d’un compteur courant. Le réutiliser pourrait prolonger une fenêtre terminée ou appliquer au mauvais demandeur la dette d’un autre.

Un intermédiaire peut produire un refus frais pour une politique qu’il contrôle. Il ne peut pas rejouer un ancien 429 comme un contenu réutilisable. L’interdiction conserve la décision auprès du composant capable d’observer encore le budget.

La précision réelle de 429

Le code ne prouve ni l’abus, ni l’intention, ni l’équité. Il n’authentifie personne, ne révèle pas l’algorithme, ne garantit pas un nouvel accès et n’oblige pas un serveur attaqué à parler. Sa valeur est plus modeste : séparer une règle de fréquence d’une erreur de contenu, fournir éventuellement une voie de retour et empêcher le refus de devenir une vérité mise en cache.

L’histoire de 429 est celle d’une décision privée devenue lisible sans devenir souveraine. Le serveur compte ; le protocole lui demande seulement de nommer honnêtement ce que ce compte lui permet de savoir.

Sources