429 Too Many Requests

Utilisation

Le code de statut 429 Too Many Requests indique que le nombre de requêtes HTTP a dépassé le seuil autorisé. Cela se produit par exemple lorsque le serveur souhaite limiter le nombre d’appels d’API par heure.

La spécification ne définit pas comment le serveur compte les requêtes HTTP ni comment il identifie les utilisateurs. La limitation de débit s’applique par ressource, par utilisateur, à l’échelle de tout le serveur, ou sur plusieurs serveurs. L’identification de l’utilisateur se fait à l’aide d’identifiants ou, à défaut, au moyen de Cookies.

Le serveur inclut facultativement un en-tête HTTP Retry-After pour indiquer au client à partir de quand les requêtes seront de nouveau acceptées.

Remarque

La limitation de débit (rate limiting) plafonne le nombre total de requêtes sur une fenêtre de temps (coupure nette), tandis que le throttling ralentit le traitement des requêtes en les mettant en file d’attente ou en retardant les réponses. La durée d’attente dépend de l’en-tête Retry-After. Sans Retry-After, les fenêtres courantes vont de 60 secondes à 24 heures selon l’API. Les utilisateurs de VPN partagent leur adresse IP avec de nombreux autres utilisateurs : les limites de débit par IP affectent donc tous les utilisateurs du VPN connectés au même serveur.

Impact SEO

Googlebot considère le 429 comme un signal d’erreur serveur. Lorsqu’un site renvoie des réponses 429, Google réduit temporairement la vitesse d’exploration sur l’ensemble du site. Une fois les réponses normales rétablies, la vitesse d’exploration remonte progressivement. Contrairement aux autres codes 4xx, les réponses 429 affectent le budget d’exploration. Des réponses 429 persistantes sur des URL indexées entraînent leur retrait des résultats de recherche. Pour ralentir Googlebot, 429 est le code de statut approprié. Les codes 401 et 403 ne réduisent pas la vitesse d’exploration. Bingbot réduit également sa vitesse d’exploration face à des réponses 429. Bing prend en outre en charge crawl-delay dans robots.txt comme alternative au throttling par code de statut.

Exemple

Le client demande une ressource et le serveur répond 429 Too Many Requests.

Requête

GET /current-news HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 429 Too Many Requests
Retry-After: 1800
Content-Type: text/html
Content-Length: 173

<html>
  <head>
    <title>Request Limit Exceeded</title>
  </head>
  <body>
   <p>The request limit has been reached.
   Try again in 30 minutes.</p>
  </body>
</html>

Comment corriger

Examinez l’en-tête Retry-After dans la réponse. Sa valeur indique soit un nombre de secondes, soit une date HTTP précisant à partir de quand le serveur accepte de nouveau les requêtes. Suspendez toutes les requêtes jusqu’à l’échéance indiquée.

Mettez en place un repli exponentiel avec jitter entre les tentatives. Doublez le temps d’attente après chaque échec (1 s, 2 s, 4 s, 8 s) et ajoutez un décalage aléatoire pour éviter que plusieurs clients ne réessaient au même instant et ne créent un nouveau pic de trafic.

Surveillez les en-têtes de limitation de débit avant d’atteindre le plafond. De nombreuses API incluent les en-têtes X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset. Suivez le compteur restant et ralentissez les requêtes de façon proactive.

Champs normalisés de limitation de débit

Au-delà des en-têtes X-RateLimit-* devenus standards de fait, l’IETF normalise les champs de réponse RateLimit et RateLimit-Policy pour signaler le quota et la réinitialisation.

Mettez en file d’attente les requêtes sortantes côté client. Une file de requêtes dotée d’un débit d’émission contrôlé empêche les rafales de dépasser la limite. Regroupez plusieurs opérations en un seul appel d’API lorsque le point de terminaison prend en charge les opérations en masse.

Mettez en cache les réponses pour les données qui ne sont pas censées changer d’une requête à l’autre. Les appels identiques redondants sont la source la plus fréquente de consommation inutile du quota de requêtes.

Côté serveur sous nginx, les directives limit_req_zone et limit_req contrôlent les limites de débit par IP ou par point de terminaison. Définissez limit_req_status 429; afin que les requêtes limitées renvoient le bon code de statut au lieu du 503 par défaut. Utilisez les paramètres burst et nodelay pour autoriser de brefs pics de trafic sans rejeter immédiatement les clients.

Pour AWS API Gateway, configurez les paramètres de throttling au niveau de l’étape (stage) ou de la méthode. Augmentez la capacité de débit et de rafale pour l’adapter aux schémas de trafic attendus lorsque les seuils par défaut sont trop restrictifs.

Références de code

.NET

HttpStatusCode.TooManyRequests

Rust

http::StatusCode::TOO_MANY_REQUESTS

Rails

:too_many_requests

http.StatusTooManyRequests

Symfony

Response::HTTP_TOO_MANY_REQUESTS

Python3.5+

http.HTTPStatus.TOO_MANY_REQUESTS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_MANY_REQUESTS

Angular

@angular/common/http/HttpStatusCode.TooManyRequests