Zusammenfassung

  • draft-ietf-httpapi-ratelimit-headers-11 lässt mehrere Richtlinien auf dieselbe Anfrage wirken; ein Server darf nur die Richtlinie anzeigen, die der Erschöpfung am nächsten ist. Nicht angezeigte Grenzen bleiben möglich.
  • r und t sind eine zeitgebundene Aussage zu einer benannten Richtlinie und Partition. Sie sind weder Kapazitätsreservierung noch Autorisierung, vollständige Zulassungsfunktion oder Nachweis eines Anwendungsergebnisses.

Der Mandant hatte 100 Einheiten seiner Tagesquote übrig. Die Stundenquote zeigte noch 900. Die Antwort nannte nur die Tagesrichtlinie, weil sie zuerst erschöpft würde. Das Dashboard speicherte den Wert jedoch ohne Richtliniennamen als remaining=100.

Nach dem Tageswechsel sprang der sichtbare Zähler auf 1.000. Das System schloss daraus, alle Grenzen seien frei. Das Stundenlimit war nie verschwunden; es war lediglich in der früheren Antwort nicht das knappste gewesen.

Die Zahl war korrekt. Das Datenmodell hatte ihren Kontext entfernt.

Die IETF-HTTPAPI-Arbeitsgruppe veröffentlichte Revision 11 von RateLimit header fields for HTTP am 23. Mai 2026. Das aktive Internet-Draft ist für den Standards Track vorgesehen und läuft am 24. November 2026 aus. Es ist kein RFC und kein Beleg für Implementierung, Verbreitung oder Interoperabilität. Seine vorgeschlagenen Begriffe zeigen aber genau, welche Teile einer Quotenentscheidung getrennt bleiben müssen.

Eine Richtlinie ist mehr als ihr letzter Restwert

RateLimit-Policy beschreibt eine benannte Quotenrichtlinie. q bezeichnet die zugeteilte Menge. Optional geben qu die Einheit, w das Zeitfenster und pk die Partition an. Revision 11 nennt Anfragen, Inhaltsbytes und gleichzeitige Anfragen als anfängliche Einheiten.

RateLimit meldet den aktuellen Dienstgrenzwert für eine bestimmte Richtlinie und Partition. r steht für die verfügbare Menge, t für das wirksame Fenster. Diese Beobachtung kann viel schneller altern als die Richtlinie.

Wer nur remaining speichert, verliert Richtlinienname, Einheit, Partition und Zeitpunkt. Ein späterer Wert kann zu einer anderen Richtlinie gehören. Zwei identische Zahlen können verschiedene Ressourcen, Nutzergruppen oder Zeithorizonte betreffen.

Ein belastbarer Datensatz enthält Herkunft, Empfangszeit, Richtlinienname, Einheit, Partition, q, w, r, t, HTTP-Status und Merkmale der auslösenden Anfrage. Erst diese Form erlaubt eine nachvollziehbare Entscheidung.

Mehrere Grenzen können gleichzeitig wahr sein

Eine Anfrage kann unter einer Tagesquote, einer Stundenquote und einem Parallelitätslimit stehen. Der Server muss nicht alle Richtlinien in jeder Antwort aufführen. Er kann diejenige melden, die der Erschöpfung am nächsten ist.

Das ist eine sinnvolle Reduktion, aber kein Vollständigkeitsbeweis. Eine nicht sichtbare Richtlinie kann weiterhin gelten. Sie kann durch andere Nutzung plötzlich zur engsten Grenze werden. Eine Änderung der Anfrage kann sie einer anderen Partition zuordnen.

Der Client darf den sichtbaren Wert deshalb zur Drosselung nutzen, aber nicht als vollständige Kopie der serverseitigen Zulassungsfunktion. „Unter der zuletzt gemeldeten Grenze“ ist eine zulässige Aussage. „Alle Grenzen erfüllt“ ist es nicht.

Diese Unterscheidung ist besonders wichtig, wenn Automatisierung Entscheidungen über mehrere Antworten hinweg zusammenführt. Ein Wert darf nur innerhalb seiner Richtlinie, Einheit, Partition und Gültigkeitszeit fortgeschrieben werden.

Verfügbar bedeutet nicht gewährt

Der Entwurf sagt ausdrücklich, dass ein positives r nicht garantiert, dass weitere Anfragen bedient werden. Im Sicherheitsabschnitt heißen verfügbare Einheiten Hinweise und nicht gewährte Anfragen oder Service-Level-Vereinbarung.

Zwischen Antwort und nächster Anfrage kann die Last steigen. Eine andere Richtlinie kann zuerst greifen. Der Server kann Werte zur Abwehr oder wegen Sättigung senken. Außerdem können Authentisierung, Autorisierung und Anwendungsvalidierung scheitern; diese Entscheidungen liegen außerhalb des RateLimit-Feldes.

Umgekehrt kann der Dienst auch bei r=0 eine Anfrage bedienen. Der Entwurf schreibt keine feste Korrelation zwischen Feldwert und Statuscode vor. Das Feld beschreibt die mitgeteilte Steuerlage, nicht die gesamte Entscheidungsmaschine.

Ein Workflow braucht daher getrennte Zustände: nach letzter Beobachtung zulässig, lokal eingeplant, abgesendet, serverseitig angenommen, ausgeführt und bestätigt. Die Quotenanzeige kann das Tempo beeinflussen, nicht die späteren Belege ersetzen.

Das wirksame Fenster ist kein Auffülltermin

t gibt in relativen Sekunden an, innerhalb welcher Zeit der Client nicht mehr als r verbrauchen sollte. Relative Zeit vermeidet Uhrensynchronisation und mindert den Effekt eines gemeinsamen absoluten Reset-Zeitpunkts.

Nach Ablauf ist die Quote nicht automatisch wieder voll. Der Text verbietet diese Annahme. Der Server darf r und t zwischen Antworten verändern, etwa bei gleitenden Fenstern, Sättigung oder adaptiver Steuerung. Das nächste Fenster kann sogar länger sein.

Ein sicherer Regler lässt die alte Beobachtung verfallen, streut den nächsten Versuch zeitlich und holt eine neue Antwort ein. Er füllt keinen lokalen Bucket nur anhand des Timers.

Retry-After kann zusätzlich einen Zeitpunkt für einen erneuten Versuch angeben. Der Entwurf empfiehlt, ihn nicht vor das Ende des wirksamen Fensters zu legen. Trotzdem bleiben Wiederholhinweis, Quotenfenster, Auffüllung und Zulassung verschiedene Aussagen.

Die Partition ist kein Identitätsnachweis

pk kann die Quotenpartition einer Anfrage benennen. Sie kann nach Nutzer, Anwendung, Methode, Ressource oder einer Kombination gebildet sein. Eine dokumentierte Regel hilft dem Client, den voraussichtlichen Topf einer künftigen Anfrage zu bestimmen.

Gleiche Schlüssel beweisen aber keine gleiche Person. Mehrere Menschen können Anmeldedaten teilen; eine Person kann mehrere Ressourcenpartitionen nutzen. Die Regel kann sich ändern. Der Entwurf warnt vor sensiblen Daten und vor Identitätsmissbrauch, wenn der Schlüssel identifizierende Informationen trägt.

Autorisierung ist ausdrücklich nicht Aufgabe der Felder. Eine Anfrage kann Quote haben und verboten sein oder berechtigt und gedrosselt werden. Selbst 401 und 403 können je nach Implementierung Einheiten verbrauchen.

Identität, Zugriffsentscheidung, Partition, aktueller Grenzwert, Zulassung und Ergebnis müssen verknüpft, aber eigenständig bleiben.

Zwischenstationen verändern die Zählung

Ein Proxy kann Anfragen wiederholen, ohne den Client zu informieren. Der Client sieht einen Geschäftsvorgang, der Dienst möglicherweise zwei Versuche und zwei verbrauchte Einheiten. Die lokale Zahl muss daher nicht mit der serverseitigen übereinstimmen.

Ein externer Vermittler sollte die Richtlinie des Ursprungs nicht großzügiger machen. Er kann sie unter Bedingungen verschärfen, wenn er die Einheit versteht und die eigene Grenze tatsächlich durchsetzt.

Trotz einer erwarteten Ablehnung soll er eine Anfrage im Regelfall weiterleiten. Der Dienst, der die Felder zurückgibt, ist für die Durchsetzung verantwortlich und darf weiterhin bedienen. Die Prognose des Proxys ist nicht die Entscheidung des Ursprungs.

Bei Differenzen braucht es Anfrage-ID, Versuch-ID, Hop, Wiederholgrund, Antwort und angewandte Richtlinie. Ein bloßer Zählervergleich beweist weder Missbrauch noch Verlust.

Großzügige Werte können Last erzeugen

Ein hohes r und kurzes t verleiten dazu, r/t als zulässige Rate zu verwenden. Diese kann weit über dem Durchschnitt liegen, den q/w der Richtlinie nahelegt. Der Entwurf beschreibt, wie dadurch Ressourcen erschöpft werden können.

Der große Wert kann von Fehlkonfiguration, einem böswilligen Vermittler oder echter kurzfristiger Reserve stammen. Der Client muss die Ursache nicht zuerst klären, um sicher zu handeln. Er begrenzt Rate, Parallelität, Speicher, Kosten und Last auf abhängige Systeme selbst, erhöht schrittweise und hält Schutzschalter aktiv.

Ein fremder Hinweis darf lokale Sicherheitsgrenzen informieren, nicht abschaffen. Sonst wird ein nicht reservierter Messwert unmittelbar zum Aktuator.

Problemtypen sind Aussagen des Dienstes

Revision 11 schlägt Problemtypen für überschrittene, vorübergehend überschrittene und als ungewöhnlich erkannte Nutzung vor. Namen verletzter Richtlinien können eine differenzierte Reaktion erlauben.

„Ungewöhnliche Nutzung erkannt“ beweist aber weder Absicht noch Identität oder korrekte Klassifikation. Die Aussage kann Drosselung, Pause und Prüfung auslösen. Für dauerhafte Sperre oder öffentliche Zuschreibung reicht sie allein nicht.

RFC 9457 liefert den Problemrahmen, RFC 6585 den Status 429, RFC 9110 allgemeine HTTP-Semantik und RFC 9651 die strukturierte Syntax. Korrekte Form macht die Aussage maschinenlesbar; sie erweitert nicht die Autorität ihres Absenders.

Quellen und Grenzen

Das eingefrorene Paket umfasst Revision 11, Datatracker-Status, Historie und Referenzen, die HTTPAPI-Arbeitsgruppe und ihren Datenschutzentwurf, RFC 9110, 9651, 6585, 9457 und 9205 sowie die IANA-Register. Es belegt den vorgeschlagenen Mechanismus und seine Grenzen, nicht Implementierung, Produktverhalten, Vorfall, Verbreitung, Leistung oder Interoperabilität.

Quellen