The X-RateLimit- family of HTTP response headers is a de-facto standard used by API implementations to communicate rate-limiting information to clients. Specifically, headers like X-RateLimit-Limit (the total requests allowed in a window), X-RateLimit-Remaining (the requests left in the window), and X-RateLimit-Reset (the time when the window resets) collectively inform the client about its current usage quota. This allows the client to proactively manage its request rate to avoid being throttled, effectively communicating the remaining capacity it can consume.

A. Throttling errors are communicated via an HTTP status code, typically 429 Too Many Requests, not in the X-RateLimit- headers themselves.

B. A correlation ID is used for distributed tracing and is typically passed in a dedicated header such as X-Correlation-ID or X-Request-ID.

C. The HTTP response size is communicated through the standard Content-Length header, which is unrelated to rate limiting.

1. MuleSoft Documentation, "Rate Limiting Policy": The official documentation for MuleSoft's Rate Limiting policy states that when the "Expose Headers" option is enabled, the policy returns X-RateLimit-Remaining, X-RateLimit-Limit, and X-RateLimit-Reset headers in the response. These headers provide the client with information about the policy's configured limits and its current status relative to those limits.

Source: MuleSoft Docs > Anypoint Platform > API Manager > Policies > Rate limiting policy > "Configuring the Rate Limiting Policy".

2. IETF Draft, "Rate-Limit Header Fields for HTTP": This document, while a draft, formalizes the common practice of using rate-limit headers. It defines RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset to "collectively indicate the current state of the client’s allowance." This directly supports the concept of communicating remaining capacity.

Source: IETF Datatracker, draft-ietf-httpapi-ratelimit-headers-11, Section 1: Introduction.