Une fonction de Worker sur ce site attache des en-têtes de sécurité à chaque réponse qu'il rend. Jusqu'à hier, deux d'entre eux étaient RateLimit-Limit : 100 et RateLimit-Policy : "default";q=100;w=60. Ils sont sortis avec la page d'accueil, avec les 24 guides, avec chaque jumeau de démarque et avec chaque 404. Ce site publie également un guide sur les en-têtes de réponse pour les agents, et ce guide enseigne à la famille RateLimit le raisonnement selon lequel un agent bien élevé lit le budget déclaré et se limite avant que quiconque doive le limiter.
Aucun code n'appliquait l'un ou l'autre numéro. Le Worker n'avait aucune logique de limitation de débit ni aucun chemin renvoyant un 429, et la configuration n'a déclaré aucun limiteur. Le 100 n'avait jamais été connecté à un compteur, donc chaque réponse annonçait un budget que le serveur n'avait aucun moyen de dépenser. Cela a fait surface pendant que je préparais les réponses aux questions les plus difficiles que l'on pouvait poser sur ce site, ce qui est la seule raison pour laquelle il a fait surface.
C’est exactement le défaut que cette entreprise vend. Une surface déclarée qu'aucun code ne résout est la première chose que recherche un audit de préparation d'un agent, et un agent suffisamment poli pour faire confiance à l'en-tête se rationnerait par rapport à une limite qui ne vivait que dans le texte.
La liaison de limitation de débit Workers de Cloudflare fait désormais le travail. La configuration est un bloc dans wrangler.jsonc nommant un limiteur avec une simple limite de 100 requêtes toutes les 60 secondes, de sorte que la configuration porte les mêmes chiffres que l'en-tête avait promis par lui-même. En haut du gestionnaire d'extraction, le Worker appelle limit() saisi sur l'adresse IP du client, et au-delà de la limite, il renvoie 429...
[Courte citation de 8% de l'article original]