L'en-tête Retry-After est un en-tête de réponse HTTP qui indique à un client combien de temps attendre avant de faire une demande de suivi. Un serveur peut l'inclure dans une réponse 429 Too Many Requests, le code d'état pour la limitation de débit. Pour un scraper, respecter cette valeur signifie faire une pause aussi longtemps que le serveur l'a demandé, au lieu de deviner et de risquer d'autres demandes bloquées.

L'en-tête est optionnel, donc une réponse 429 peut arriver sans lui. La RFC 6585 ne définit également pas comment un serveur identifie l'utilisateur ou compte les demandes. Une limite peut être liée à des identifiants de connexion ou à un cookie, et pas seulement à une adresse IP.

Formats de valeur Retry-After

  • Délai en secondes : Un nombre entier non négatif, tel que Retry-After: 120.
  • Date HTTP : Une date après laquelle réessayer, telle que Retry-After: Wed, 21 Oct 2015 07:28:00 GMT.
  • Où il apparaît : Avec les réponses 429, avec 503 Service Unavailable pour montrer combien de temps l'interruption devrait durer, et avec des redirections telles que 301 pour définir un temps d'attente minimum.

Autres en-têtes de limitation de débit

  • En-têtes de fournisseur : Certaines API ajoutent leurs propres champs. L'API REST de GitHub, par exemple, envoie x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-used et x-ratelimit-reset.
  • Norme proposée : Un projet Internet de l'IETF définit les champs RateLimit et RateLimit-Policy afin que les serveurs puissent annoncer les politiques de quota et le quota restant. C'est encore un projet, pas une RFC publiée.
  • Logique de réessai : GitHub conseille d'attendre le nombre de secondes dans retry-after lorsqu'il est présent, et d'augmenter l'attente de manière exponentielle si les demandes continuent d'échouer.

Qui respecte Retry-After

  • Le support varie : MDN note que le support client et serveur pour Retry-After est encore incohérent.
  • Crawlers de recherche : Certains crawlers, comme Googlebot, le respectent. Google dit qu'un site peut envoyer Retry-After avec une réponse 503 ou 429 pour indiquer à son crawler quand réessayer.
  • Gardez-le court : Google déconseille de servir 500, 503 ou 429 pour ralentir le crawling pendant plus de 1 à 2 jours. Si Googlebot voit ces codes sur la même URL pendant plusieurs jours, il peut retirer cette URL de son index.

Termes associés