HTTP Rate Limiting
Frappe Framework includes built-in HTTP rate limiting to protect applications from excessive requests and resource abuse. Instead of limiting the number of requests, Frappe limits the total processing time consumed by HTTP requests within a configurable time window.
How It Works
Rate limiting uses a fixed-window approach. The framework tracks the cumulative time spent processing HTTP requests during a configured time window. Once the allowed processing time is exhausted, additional requests are rejected until the window resets.
Enable Rate Limiting
To enable HTTP rate limiting for a site, add the following configuration to the site’s site_config.json file.
{
"rate_limit": {
"limit": 600,
"window": 3600
}
}
In this example, the site allows a total of 600 seconds of request processing time within a 3600-second (1 hour) window. At the beginning of every new window, the usage counter is automatically reset based on the site’s timezone.
Requests that exceed the configured limit are not processed. Instead, the server responds with an HTTP 429 (Too Many Requests) status.
Configuration Options
| Setting | Description |
|---|---|
limit |
Maximum cumulative request processing time allowed during a rate limit window (in seconds). |
window |
Length of the rate limit window before usage counters are reset (in seconds). |
Successful Response Headers
Every successful HTTP response includes headers that show the current rate limit status.
curl -i https://frappe.io/docs
HTTP/1.1 200 OK
X-RateLimit-Limit: 600000000
X-RateLimit-Remaining: 518060453
X-RateLimit-Reset: 3513
X-RateLimit-Used: 100560
These headers allow clients to monitor their current usage and estimate how much processing time remains before reaching the configured limit.
Rate Limit Exceeded Response
Once the available processing time has been exhausted, Frappe rejects additional requests and returns an HTTP 429 response.
curl -i https://frappe.io/docs
HTTP/1.1 429 TOO MANY REQUESTS
X-RateLimit-Limit: 600000000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1242
Retry-After: 1242
The Retry-After header tells clients how long they should wait before sending new requests.
HTTP Response Headers
| Header | Description |
|---|---|
Retry-After |
Number of seconds remaining until the current rate limit window resets. |
X-RateLimit-Limit |
Total processing time permitted within the current window (in microseconds). |
X-RateLimit-Remaining |
Remaining processing time available before the limit is reached (in microseconds). |
X-RateLimit-Reset |
Time remaining until the rate limit window resets (in seconds). |
X-RateLimit-Used |
Processing time consumed by the current request (in microseconds). |
Best Practice
Configure rate limits based on your application’s expected traffic and server capacity. Client applications should monitor the returned rate limit headers and respect the Retry-After value when receiving an HTTP 429 response to avoid repeated request failures.