Summary

  • draft-ietf-httpapi-ratelimit-headers-11 defines a server signal about a named quota policy, partition and current service limit; it explicitly says positive available quota is not a guarantee that later requests will be served.
  • The safe chain keeps policy, observation, client pacing, partition selection, request admission, authorization, execution and business outcome separate. r=50;t=30 is useful evidence for the first three, not a reservation for the last five.

The fleet controller received a successful response with RateLimit: "default";r=50;t=30. It opened fifty jobs immediately. In its local ledger, those jobs were no longer merely eligible to try; they had become fifty promised execution slots.

Before the burst reached the service, another tenant changed the load profile. The server tightened its adaptive limit. An intermediary retried two requests after a connection failure. Several calls mapped to a different partition because they addressed another resource. Three failed authorization, and four were accepted but later rejected by application validation.

The header had not lied. The controller had promoted a current hint into a future right.

Revision 11 of RateLimit header fields for HTTP was published on 23 May 2026 by the IETF HTTPAPI Working Group. It is an active Internet-Draft intended for the Standards Track and expires on 24 November 2026. It is not an RFC, a deployment report or proof that any named service implements the design. Its value here is narrower and more durable: it specifies a vocabulary that makes an important authority boundary unusually explicit.

A policy is not the observation made under it

RateLimit-Policy describes a quota policy. A policy item has a name, a required quota q, and may include a unit qu, a window w and a partition key pk. The draft initially defines request, content-byte and concurrent-request units. Even within the request unit, whether a specific request consumes one is implementation-specific.

RateLimit answers a different question. It reports a current service limit for a named policy and partition. Its required r parameter is the available quota; its optional t parameter is the effective window during which the client should use no more than that amount. A system that stores both fields as one scalar called requests_remaining loses the policy identity, unit, partition and observation horizon needed to interpret the number.

More than one policy can govern the same request. A daily allocation and an hourly allocation can both be real, while the server advertises only the one closest to exhaustion. The absence of another policy from a response does not prove that it does not exist. A client therefore cannot reconstruct the complete admission function from a single field value.

The disciplined record is a tuple: origin service, response time, policy name, unit, partition key, q, w, r, t, response status and request characteristics. That tuple is evidence of what the server communicated. It is not yet evidence of what a later request encountered.

Positive quota is not a grant

The draft is direct: clients must not assume that positive available quota guarantees that further requests will be served. Its security section labels the same boundary from another angle—available quota units are hints, not granted requests, and must not be treated as a service-level agreement.

This is not a weakness in the mechanism. A service cannot generally reserve future capacity merely by reporting its current control state. Saturation can arrive between responses. A protection system can lower limits. Another policy can bind first. A request can fail authentication, authorization, validation or dependency checks that are outside rate limiting. The service can even choose to serve a request when r=0; the draft mandates no fixed correlation between the field and response status.

The useful promise is therefore behavioral, not transactional. The signal helps a client avoid avoidable throttling. It gives a cooperative controller information with which to reduce pressure. It does not transfer enforcement authority from server to client, nor does it create a claim against capacity.

A queue may classify the next request as within the last observed service limit. It may not classify it as admitted. Admission needs the later server response. Execution needs an application receipt. Outcome needs evidence from the consumer or governed object.

The window does not refill the bucket

The t parameter is expressed as a delay in seconds. This avoids reliance on synchronized clocks and reduces the risk of many clients waking on one absolute reset timestamp. Yet t is not a countdown to restoration.

The draft says a client must not assume that all service limit will be restored after the effective window. The server may alter both available quota and window between requests, including for sliding-window control or resource saturation. A subsequent response may even carry a larger t, extending the period during which the client should remain restrained.

That distinction changes scheduling. A naive controller waits thirty seconds, replenishes its local bucket to fifty and releases a synchronized wave. A careful controller treats the old observation as expired. It waits at least as its policy requires, adds jitter, makes a bounded probe, reads the new response and adjusts gradually. The old t constrains what it should not consume; it does not certify what the server will offer afterward.

Retry-After has adjacent but different semantics. When the service sends it alongside these fields, the draft recommends that its indicated time not fall before the effective window ends. That coordination does not make the two values interchangeable. Retry advice, quota horizon and actual admission remain separate observations.

A partition is not a person

Servers can partition quota by user, application, method, resource or combinations. The optional pk value lets the response name the relevant partition as a byte sequence. A documented generation rule can help the client decide whether a future request is likely to draw from the same pool.

The temptation is to turn a stable partition key into identity. That is an unsupported promotion. Two requests can share a quota partition without sharing a human principal; one principal can occupy several partitions; a gateway can partition on method or resource; and the server can change its strategy. The draft warns against placing sensitive information in the value and notes impersonation risk where a key contains identifying information.

Partition equality supports one bounded inference: the service says these requests are accounted against the same advertised quota partition under its present rule. It does not prove authentication, authorization, tenancy, ownership or fairness. Those claims need their own evidence.

This also explains why authorization is expressly out of scope. A caller can be under quota and forbidden. It can be authorized and out of quota. A 401 or 403 might itself consume quota, depending on the implementation. Rate-limit state and access-control state meet inside the service, but neither substitutes for the other.

Intermediaries can change the path, not the origin's authority

Rate-limit fields travel through gateways, proxies and other intermediaries. An intermediary outside the originating infrastructure should not make the advertised policy more permissive. Under defined conditions, it may make the signal more restrictive when it understands the unit and enforces its own constraint.

Even then, the draft tells an intermediary normally to forward a request it expects might not be serviced. The service returning the fields remains responsible for enforcing its communicated policy and remains free to serve the request. That preserves a clean authority line: advisory reasoning at the intermediary does not become the origin's admission decision.

The path also changes accounting. A proxy can retry a request without telling the user agent, consuming quota units the client never represented in its local count. Conversely, a request the client prepared may never reach the enforcing service. A discrepancy between client submissions and server quota consumption is not automatically fraud or implementation failure; it is a prompt to inspect the hop-by-hop receipt chain.

Operational records should therefore capture intermediary retry identifiers, attempt counts and the service response that supplied each quota observation. Without that lineage, a client can only compare two counters and invent the cause of their difference.

A large allowance can be dangerous

Hints can cause load, not merely restrain it. The draft gives the case of a large long-window policy paired with a short effective window. A simple client might divide available quota by t and infer a rate far above the average implied by q/w. The resulting burst can exhaust the service.

An unexpectedly high value might come from a malicious intermediary, a misconfigured server or a legitimate change the client is not equipped to exploit safely. The client remains accountable for its own maximum rate, concurrency, memory, cost and downstream pressure. It should cap values, add jitter, ramp rather than leap, and preserve circuit breakers that do not disappear when the server appears generous.

That is a crucial governance point. A cooperative signal can inform local policy; it cannot repeal it. If the client hands its actuator directly to a remote integer, it has delegated operational safety to an observation that the specification itself tells it not to treat as a grant.

Problem details classify; they do not convict

Revision 11 defines problem types for exceeded quota, temporary quota exhaustion and abnormal usage detection. These can identify violated policy names and let automation distinguish conditions more cleanly than prose.

The type is still a statement by the responding service. “Abnormal usage detected” does not independently prove malicious intent, identify the person behind a client or establish that the classifier was correct. It can justify a reversible client response—slow down, stop a batch, request review—without justifying an irreversible accusation.

RFC 9457 supplies the problem-details container. RFC 6585 supplies 429. RFC 9110 supplies the general field and status semantics. RFC 9651 makes the list and parameter syntax precise. Together they improve the quality of the receipt. None enlarges the claim beyond the authority of its producer.

Sources and limits

The frozen packet contains revision 11 and its Datatracker record, history and references; the HTTPAPI charter and privacy work; RFCs 9110, 9651, 6585, 9457 and 9205; and the IANA HTTP field and problem-type registries. They establish the proposed protocol mechanics and their stated limits. They do not establish deployment, adoption, vendor behavior, a real incident, performance or interoperability.

Sources