Summary

  • HTTP 429 describes a request stream that has crossed a server-defined budget. It does not say that the request is malformed, identify a natural person or define how requests must be counted.
  • RFC 6585 encouraged an explanation and allowed Retry-After, but a delay is guidance rather than a reservation. A later attempt still faces current policy, capacity, authorization and resource state.
  • The code makes hidden accounting visible enough for recovery. Fairness still depends on the operator's identity key, scope, counter placement and refusal cost—and under attack the standard permits dropping connections instead.

The fiftieth request was not broken

Imagine an API that accepts fifty requests per hour from each signed-in account. The first fifty messages can be well formed. The next one can be byte-for-byte identical to a request that succeeded moments earlier. Its credentials can still be valid, its target can still exist and its operation can still make sense. What changed is not the message. A counter behind the message crossed a line.

Before HTTP had a specific answer for this condition, a service could return a generic client error or present overload as if the entire server had failed. Neither description exposed the decision a client needed to make. Should it correct the request, change credentials, choose another resource, wait, or stop? In April 2012, RFC 6585 registered 429 Too Many Requests as a more precise response.

That precision is carefully bounded. The RFC says the user sent too many requests in a given amount of time. It says the response should explain the condition and may include Retry-After. It also says something more revealing: the specification does not define how the origin identifies the user or how it counts requests.

The code standardized a verdict, not the ledger behind it.

“User” is a slot in an accounting system

In ordinary speech, a user is a person. In a rate limiter, the counted subject might be an authenticated account, an API key, a session cookie, a tenant, a source address or a combination chosen by the operator. RFC 6585 gives credentials and a stateful cookie as examples. It does not certify that either points to one human being.

That distinction matters at the edge of the network. Thousands of subscribers can emerge through one carrier-grade NAT address. An office can send all staff traffic through one egress. A privacy relay can deliberately separate a person's identity from the address visible to the service. If the cheapest early limiter counts only the address, unrelated people can inherit one another's traffic history. The resulting 429 is a valid protocol response to a locally computed counter; it is not proof that each rejected person exceeded a personal allowance.

Authentication offers a different boundary, not a perfect one. One account can drive many devices. One credential can be shared or stolen. A key can identify a customer contract more reliably than a process. The operator must choose the identity evidence that matches the capacity being allocated and disclose enough of that choice for a rejected client to recover.

This follows a wider rule of Internet authority: a signal should carry no more power than its evidence supports. An IP address can support an address-scoped counter. It cannot, by itself, authorize a judgment about a person.

The scope of the counter is part of the decision

RFC 6585 allows counting per resource, across an entire server or among a set of servers. Those possibilities produce different systems while emitting the same three digits.

A per-resource counter can protect an expensive search endpoint without blocking account settings. A server-wide counter is easier to explain but can make a cheap health check consume the same unit as a costly report. A tenant-wide counter can match a commercial allocation, provided every request is mapped to the right tenant. A fleet-wide counter can enforce one allowance across regions, but it has to decide how distributed increments converge and what happens when its state service is unavailable.

Even “one request” is not self-defining. Is the unit an arrival, an authenticated request, an admitted operation or a completed response? Does a redirect consume another unit? Does a cancelled HTTP/2 stream count? What about a proxy retry that the application never requested? The wire status cannot answer these questions because they belong to the operating system behind the origin.

An inaccurate counter can deny legitimate work or admit excess load while every emitted 429 remains syntactically correct. Protocol conformance is therefore not an audit of the accounting policy.

A clock can advise without granting permission

RFC 6585 permits a 429 response to include Retry-After. Current HTTP semantics allow that field to contain either an HTTP date or a non-negative number of delay seconds. The difference is practical. An absolute date requires the parties to interpret a shared time reference; delay seconds start from receipt of the response. Neither form creates a booking.

The client is being asked to wait before a follow-up request. It has not bought the first place in a future queue. At the suggested boundary, other traffic may have consumed capacity, the service may have changed its policy, the credentials may no longer be authorized or the underlying resource may have changed. A client that releases a whole backlog at the same second can produce a new surge precisely because it followed the visible time too literally.

Good recovery therefore combines the server's hint with local restraint: bounded retries, some spreading of wake-up times, an expiry for work that is no longer useful and method-aware treatment of side effects. A POST does not become safe to repeat merely because a timer ended. Retry-After describes time; it does not establish the final outcome of an operation during an uncertain transport failure.

429 is not a smaller 503

Both 429 and 503 Service Unavailable can appear beside Retry-After, but they place the refusal on different surfaces. RFC 9110 defines 503 as temporary inability to handle the request because of overload or scheduled maintenance. The service is describing its own present incapacity. A 429 attributes the operative limit to too many requests from the subject selected by the server's rate policy.

The distinction lets one account or resource be limited while other work continues. It also imposes a duty of honesty. A service-wide capacity failure should not be narrated as one client's misconduct merely because a 4xx code transfers blame more conveniently. Conversely, one exhausted tenant budget need not tell every client that the entire service is unavailable.

Reality can contain both. A platform can have per-account quotas and global overload protection. The useful status is the one that explains the branch actually taken. The code should expose the control surface, not decorate it.

Refusal has a cost

The most important limit in RFC 6585 appears in its security considerations. If a server is under attack, responding to every request with 429 consumes resources. The standard therefore does not require the response in every case; dropping connections or taking other measures may be more appropriate.

Producing a refusal can require parsing a message, completing cryptography, finding credentials, consulting a distributed counter, rendering an explanation and sending encrypted bytes. A defensive system that performs all of that before saying no can lose the resource it intended to protect. An edge can reject earlier, but only if it has enough trustworthy information to apply the intended scope. Earlier action with weaker identity can reduce computing cost while increasing collateral denial.

This is not a failure of interoperability. It is a statement about proportional authority. Explanation is valuable when the system can afford it. Survival can require silence when explanation itself becomes the attack surface.

A refusal that must not become reusable content

RFC 6585 prohibits a cache from storing a 429 response. The rule follows from the verdict's nature. A rate-limit result is tied to time, the attributed subject, the request scope and a current counter. Replaying it later can extend a window that has ended or apply one subject's refusal to another request context.

An intermediary can enforce a rate policy it owns and generate a fresh refusal. It cannot treat an old 429 as reusable representation content. The prohibition keeps a contingent accounting decision attached to the system that can still observe the counter.

What the three digits cannot prove

A 429 response does not authenticate the user. It does not prove malicious intent, abuse or even a fair allocation. It does not reveal whether the counter is exact, eventually consistent or unavailable. It does not promise that waiting will succeed. It does not require every overloaded server to explain itself.

What it can do is narrower and valuable. It lets a server distinguish a rate-policy refusal from malformed content and from general service inability. It lets a client recognize that immediate repetition is unlikely to help. When the operator supplies an actionable explanation and a credible delay, automated recovery can become calmer and more predictable.

The history of 429 is therefore not the story of HTTP inventing quotas. It is the story of HTTP making a private capacity decision speak in a common voice while refusing to turn that voice into universal authority.

Sources