# HTTP RateLimit headers

DevFeed: [HTTP RateLimit headers](<https://devfeed.tech/articles/http-ratelimit-headers-36227.md>)

Original publisher: [Read original article](<https://dotat.at/@/2026-01-13-http-ratelimit.html>)

Published: 2026-01-14T02:34:22Z

Content type: article

Language: en

Sources: [Tony Finch's blog](<https://devfeed.tech/sources/tony-finch-s-blog.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [Algorithms](<https://devfeed.tech/topics/algorithms.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [client](<https://devfeed.tech/topics/client.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [client](<https://devfeed.tech/tags/client.md>), [headers](<https://devfeed.tech/tags/headers.md>), [http](<https://devfeed.tech/tags/http.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

The article examines the IETF draft for HTTP RateLimit headers and argues that the headers can support linear rate-limit algorithms such as GCRA, encouraging smoother client request behavior than quota-reset algorithms.

## Source excerpt

There is an IETF draft that aims to standardize RateLimit header fields for HTTP. A RateLimit header in a successful response can inform a client when it might expect to be throttled, so it can avoid 429 Too Many Requests errors. Servers can also include RateLimit headers in a 429 response to make the error more informative. The draft is in reasonably good shape. However as written it seems to require (or at least it assumes) that the server uses bad quota-reset rate limit algorithms. Quota-reset algorithms encourage clients into cyclic burst-pause behaviour; the draft has several paragraphs discussing this problem. However, if we consider that RateLimit headers are supposed to tell the client what acceptable behaviour looks like, they can be used with any rate limit algorithm. (And it isn't too hard to rephrase the draft so that it is written in terms of client behaviour instead of server behaviour.) When a client has more work to do than will fit in a single window's quota, linear rate limit algorithms such as GCRA encourage the client to smooth out its requests nicely. In this article I'll describe how a server can use a linear rate limit algorithm with HTTP RateLimit headers. spec summary policy parameters linear rate limit algorithm other rate limiters spec summary The draft specifies two headers: RateLimit-Policy: describes input parameters to a rate limit algorithm, which the server chooses based on the request in some unspecified way. The policies are expected to be largely static for a particular client. The parameters are, the name of the policy pk, the partition key q, the quota w, the window qu, the quota units RateLimit: describes which policies the server applied to this request, and the output results of the rate limit algorithm. The results are likely to vary per request depending on client behaviour or server load, etc. The results are, the name of the policy pk, the partition key r, the available quota t, the effective window Both headers can list