Zusammenfassung

  • 429 bedeutet, dass eine vom Server zusammengefasste Folge von Anfragen ein lokal bestimmtes Budget überschritten hat. Der Status beweist weder fehlerhaften Inhalt noch Missbrauch durch eine bestimmte Person.
  • Retry-After kann eine Wartezeit nennen, reserviert aber keine spätere Kapazität. Beim nächsten Versuch gelten weiterhin die dann aktuelle Last, Berechtigung, Regel und Ressource.
  • RFC 6585 definiert weder Benutzeridentifikation noch Zählverfahren. Die gemeinsame Antwort macht den verborgenen Zähler sichtbar, bestätigt aber nicht seine Richtigkeit oder Fairness.

Die Anfrage hinter dem Strich

Ein Dienst akzeptiert fünfzig Aufrufe pro Stunde für jedes angemeldete Konto. Der nächste Aufruf kann exakt dieselbe gültige Struktur, dasselbe Ziel und dieselbe Berechtigung besitzen. Seine Ablehnung erklärt sich nicht aus dem einzelnen Dokument, sondern aus einem Gedächtnis des Servers: Dieser Aufruf wurde einer früheren Reihe zugerechnet, deren Grenzwert erreicht ist.

Für diese Lage registrierte RFC 6585 im April 2012 429 Too Many Requests. Ein unspezifischer 4xx-Fehler hätte den Client zur Korrektur eines tadellosen Inhalts verleiten können. 503 hätte eine vorübergehende Unfähigkeit des Dienstes beschrieben, obwohl andere Konten oder Ressourcen womöglich weiter arbeiteten. 429 bezeichnet stattdessen eine vom Server zugeschriebene Anfragerate.

Die Spezifikation empfiehlt eine Erklärung und erlaubt Retry-After. Zugleich sagt sie ausdrücklich, dass sie weder die Identifizierung des Benutzers noch die Zählweise des Ursprungsservers festlegt. Vereinheitlicht wurde das Urteil, nicht das Buch, aus dem es stammt.

Ein gezählter Benutzer muss kein einzelner Mensch sein

Für eine frühe Entscheidung braucht der Server einen Schlüssel. Das kann ein Konto, API-Schlüssel, Cookie, Mandant, eine Quelladresse oder eine Kombination sein. Die in RFC 6585 erwähnten Zugangsdaten und zustandsbehafteten Cookies sind Möglichkeiten, keine Identitätszertifikate.

Die IP-Adresse ist am Netzrand günstig verfügbar und gerade deshalb gefährlich bequem. Hinter Carrier-NAT, einem Unternehmensausgang oder einem Datenschutz-Relay können viele Unbeteiligte gleich aussehen. Ein einziger starker Sender verbraucht dann das Budget aller. Die Antwort ist für einen Adresszähler möglich, aber keine Evidenz dafür, dass jede abgewiesene Person ihre eigene Grenze überschritt.

Ein authentifiziertes Konto bildet Verträge oft besser ab, kann jedoch mehrere Geräte, Prozesse oder Mitarbeitende umfassen. Schlüssel können geteilt oder gestohlen werden. Cookies belegen eine Sitzung, nicht zwingend eine Person. Aus jedem Signal folgt nur eine begrenzte Aussage.

429 darf deshalb nicht von „dieser Zähleinheit ist erschöpft“ zu „dieser Mensch hat missbraucht“ aufsteigen. Autorität muss bei der nachgewiesenen Zuordnung enden.

Drei Ziffern, viele Geltungsbereiche

RFC 6585 nennt Zählung pro Ressource, über den gesamten Server oder über mehrere Server. Ein ressourcenbezogenes Limit kann eine teure Suche schützen und einfache Einstellungen offenlassen. Ein Gesamtlimit schützt gemeinsame Kapazität, bewertet aber womöglich einen kleinen Abruf genauso wie eine aufwendige Analyse.

Mandantenlimits können zu einer vertraglichen Zuteilung passen, wenn jede Anfrage zuverlässig zugeordnet wird. Ein regionsübergreifender Zähler hält ein gemeinsames Budget, muss aber Replikationsverzug, Netzpartitionen und Ausfälle seines Zustandsspeichers behandeln.

Auch das gezählte Ereignis ist eine Entscheidung. Wird beim Eingang, nach Authentifizierung, bei Zulassung oder nach Abschluss erhöht? Kostet eine Weiterleitung erneut? Bleibt ein abgebrochener HTTP/2-Stream im Saldo? Wer bezahlt einen automatischen Proxy-Wiederholungsversuch? HTTP kann dies nicht allgemein festlegen, ohne die lokale Ausführung zu übernehmen.

Ein ungenauer Zähler kann vollkommen korrekt formatierte 429-Antworten erzeugen. Protokolltreue ist keine Prüfung der Abrechnung.

Eine Warteangabe ist keine Buchung

RFC 9110 erlaubt für Retry-After ein HTTP-Datum oder eine nicht negative Zahl von Sekunden. RFC 6585 gestattet das Feld bei 429. Es sagt, wann der Agent nicht zu früh wiederkommen soll; es verspricht keinen freien Platz.

Ein Datum verlangt eine brauchbare Zeitreferenz, Verzögerungssekunden beginnen beim Empfang. Beide Formen können Clients an derselben Kante synchronisieren. Bis dahin können andere Nachfrage, neue Regeln, geänderte Berechtigungen oder ein anderer Ressourcenzustand den nächsten Entscheid bestimmen.

Robuste Clients brauchen daher eigene Grenzen: verteilte Wiederaufnahme, eine Höchstzahl von Versuchen, fachliche Fristen und methodengerechte Behandlung von Wirkungen. Eine nicht idempotente Operation wird nicht durch Ablauf der Uhr wiederholbar. Bei einem Transportabbruch beweist die Zeit nicht, ob ein früherer Versuch wirkte.

429 ist nicht bloß die kleinere 503

RFC 9110 beschreibt 503 als vorübergehende Unfähigkeit des Servers wegen Überlastung oder Wartung. 429 beschreibt zu viele Anfragen für das von der Rate-Regel gewählte Subjekt. Beide können Retry-After verwenden, aber sie verorten die Entscheidung unterschiedlich.

Ein Mandant kann 429 erhalten, während andere weiterarbeiten. Ein ganzer Dienst kann 503 liefern, ohne dass ein einzelnes Konto seine Zuteilung überschritt. Wo beide Schutzmechanismen bestehen, soll der Status die tatsächlich entscheidende Bedingung nennen.

Ein allgemeiner Kapazitätsmangel darf nicht als Fehlverhalten eines Clients erzählt werden. Ein lokales Budget darf nicht jede übrige Route unsichtbar machen. Präzise Statuscodes sind auch präzise Verantwortungsangaben.

Auch ein Nein braucht Ressourcen

Die Sicherheitsbetrachtung von RFC 6585 warnt davor, dass eine 429-Antwort auf jede Anfrage während eines Angriffs selbst Ressourcen verbraucht. Der Server muss den Code daher nicht immer verwenden; Verbindungen zu verwerfen oder anders zu reagieren kann angemessener sein.

Vor einer höflichen Ablehnung können Entschlüsselung, Parsing, Authentifizierung, verteilter Zählerzugriff, Inhaltsaufbau und verschlüsselte Übertragung liegen. Erzwingt eine billige Eingabe diesen ganzen Weg, wird Erklärung zur Angriffsfläche. Frühes Filtern spart Arbeit, sieht aber häufig nur schwächere Identität und erhöht das Risiko gemeinsamer Sperren.

Die Entscheidung muss Kosten und Evidenz zusammenhalten. Je weniger der frühe Punkt weiß, desto enger und reversibler muss seine Maßnahme sein.

Warum ein Cache das Urteil nicht verlängern darf

RFC 6585 verbietet das Speichern von 429-Antworten. Das Urteil hängt von Subjekt, Zeitfenster, Bereich und aktuellem Zähler ab. Eine Wiederverwendung könnte nach Ablauf des Fensters weiter ablehnen oder den Stand eines Subjekts auf einen anderen Kontext übertragen.

Ein Vermittler darf für eine eigene Kapazitätsregel eine neue Antwort erzeugen. Er darf keine alte Ablehnung als wiederverwendbare Repräsentation behandeln. Die Entscheidung bleibt dort, wo der aktuelle Stand beobachtet werden kann.

Was 429 wirklich behauptet

Der Code authentifiziert niemanden, beweist keine Absicht, zertifiziert keine Fairness und garantiert keinen späteren Erfolg. Er schreibt auch nicht vor, dass ein angegriffener Server jede Ablehnung erklären muss.

Sein enger Nutzen ist dennoch groß: Ein Client kann Ratenpolitik von ungültigem Inhalt und allgemeiner Dienstunfähigkeit unterscheiden. Sofortige Wiederholung wird als schlechte Strategie erkennbar. Eine verantwortliche Erklärung kann eine ruhige Rückkehr ermöglichen.

Die Geschichte von 429 handelt nicht von einer durch HTTP erfundenen Quote. Sie handelt davon, wie ein lokales Kapazitätsurteil gemeinsam verständlich wurde, ohne dadurch allgemein legitimiert zu sein.

Quellen