draft-ietf-httpapi-ratelimit-headers-01.unpg.txt   draft-ietf-httpapi-ratelimit-headers-latest.txt 
HTTPAPI Working Group R. Polli HTTPAPI Working Group R. Polli
Internet-Draft Team Digitale, Italian Government Internet-Draft Team Digitale, Italian Government
Intended status: Standards Track A. Martinez Intended status: Standards Track A. Martinez
Expires: November 12, 2021 Red Hat Expires: March 17, 2022 Red Hat
May 11, 2021 September 13, 2021
RateLimit Header Fields for HTTP RateLimit Header Fields for HTTP
draft-ietf-httpapi-ratelimit-headers-01 draft-ietf-httpapi-ratelimit-headers-latest
Abstract Abstract
This document defines the RateLimit-Limit, RateLimit-Remaining, This document defines the RateLimit-Limit, RateLimit-Remaining,
RateLimit-Reset fields for HTTP, thus allowing servers to publish RateLimit-Reset fields for HTTP, thus allowing servers to publish
current service limits and clients to shape their request policy and current service limits and clients to shape their request policy and
avoid being throttled out. avoid being throttled out.
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (httpapi@ietf.org), which is archived at mailing list (httpapi@ietf.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-httpapi-wg/ [1]. https://mailarchive.ietf.org/arch/browse/httpapi/ [1].
The source code and issues list for this draft can be found at The source code and issues list for this draft can be found at
https://github.com/ietf-wg-httpapi/ratelimit-headers [2]. https://github.com/ietf-wg-httpapi/ratelimit-headers [2].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2021. This Internet-Draft will expire on March 17, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rate-limiting and quotas 1.1. Rate-limiting and quotas . . . . . . . . . . . . . . . . 3
1.2. Current landscape of rate-limiting headers 1.2. Current landscape of rate-limiting headers . . . . . . . 4
1.2.1. Interoperability issues 1.2.1. Interoperability issues . . . . . . . . . . . . . . . 4
1.3. This proposal 1.3. This proposal . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Goals 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Notational Conventions 1.5. Notational Conventions . . . . . . . . . . . . . . . . . 6
2. Expressing rate-limit policies 2. Expressing rate-limit policies . . . . . . . . . . . . . . . 6
2.1. Time window 2.1. Time window . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Service limit 2.2. Service limit . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Quota policy 2.3. Quota policy . . . . . . . . . . . . . . . . . . . . . . 7
3. Header Specifications 3. Header Specifications . . . . . . . . . . . . . . . . . . . . 8
3.1. RateLimit-Limit 3.1. RateLimit-Limit . . . . . . . . . . . . . . . . . . . . . 8
3.2. RateLimit-Remaining 3.2. RateLimit-Remaining . . . . . . . . . . . . . . . . . . . 9
3.3. RateLimit-Reset 3.3. RateLimit-Reset . . . . . . . . . . . . . . . . . . . . . 9
4. Providing RateLimit fields 4. Providing RateLimit fields . . . . . . . . . . . . . . . . . 10
4.1. Performance considerations 4.1. Performance considerations . . . . . . . . . . . . . . . 11
5. Intermediaries 5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 12
6. Caching 6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Receiving RateLimit fields 7. Receiving RateLimit fields . . . . . . . . . . . . . . . . . 12
8. Examples 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Unparameterized responses 8.1. Unparameterized responses . . . . . . . . . . . . . . . . 13
8.1.1. Throttling information in responses 8.1.1. Throttling information in responses . . . . . . . . . 13
8.1.2. Use in conjunction with custom fields 8.1.2. Use in conjunction with custom fields . . . . . . . . 14
8.1.3. Use for limiting concurrency 8.1.3. Use for limiting concurrency . . . . . . . . . . . . 15
8.1.4. Use in throttled responses 8.1.4. Use in throttled responses . . . . . . . . . . . . . 16
8.2. Parameterized responses 8.2. Parameterized responses . . . . . . . . . . . . . . . . . 17
8.2.1. Throttling window specified via parameter 8.2.1. Throttling window specified via parameter . . . . . . 17
8.2.2. Dynamic limits with parameterized windows 8.2.2. Dynamic limits with parameterized windows . . . . . . 17
8.2.3. Dynamic limits for pushing back and slowing down 8.2.3. Dynamic limits for pushing back and slowing down . . 18
8.3. Dynamic limits for pushing back with Retry-After and slow 8.3. Dynamic limits for pushing back with Retry-After and slow
down down . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3.1. Missing Remaining information 8.3.1. Missing Remaining information . . . . . . . . . . . . 20
8.3.2. Use with multiple windows 8.3.2. Use with multiple windows . . . . . . . . . . . . . . 20
9. Security Considerations 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Throttling does not prevent clients from issuing requests 9.1. Throttling does not prevent clients from issuing requests 21
9.2. Information disclosure 9.2. Information disclosure . . . . . . . . . . . . . . . . . 21
9.3. Remaining quota-units are not granted requests 9.3. Remaining quota-units are not granted requests . . . . . 22
9.4. Reliability of RateLimit-Reset 9.4. Reliability of RateLimit-Reset . . . . . . . . . . . . . 22
9.5. Resource exhaustion 9.5. Resource exhaustion . . . . . . . . . . . . . . . . . . . 22
9.6. Denial of Service 9.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.1. RateLimit-Limit Field Registration 10.1. RateLimit-Limit Field Registration . . . . . . . . . . . 23
10.2. RateLimit-Remaining Field Registration 10.2. RateLimit-Remaining Field Registration . . . . . . . . . 24
10.3. RateLimit-Reset Field Registration 10.3. RateLimit-Reset Field Registration . . . . . . . . . . . 24
11. References 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References 11.2. Informative References . . . . . . . . . . . . . . . . . 25
11.3. URIs 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix B. FAQ Appendix B. FAQ . . . . . . . . . . . . . . . . . . . . . . . . 26
RateLimit fields currently used on the web RateLimit fields currently used on the web . . . . . . . . . . . 29
Changes Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
D.1. Since draft-ietf-httpapi-ratelimit-headers-00 D.1. Since draft-ietf-httpapi-ratelimit-headers-00 . . . . . . 30
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The widespreading of HTTP as a distributed computation protocol The widespreading of HTTP as a distributed computation protocol
requires an explicit way of communicating service status and usage requires an explicit way of communicating service status and usage
quotas. quotas.
This was partially addressed by the "Retry-After" header field This was partially addressed by the "Retry-After" header field
defined in [SEMANTICS] to be returned in "429 Too Many Requests" (see defined in [SEMANTICS] to be returned in "429 Too Many Requests" (see
[STATUS429]) or "503 Service Unavailable" responses. [STATUS429]) or "503 Service Unavailable" responses.
skipping to change at line 152 skipping to change at page 4, line 15
When quota is exceeded, servers usually do not serve the request When quota is exceeded, servers usually do not serve the request
replying instead with a "4xx" HTTP status code (eg. 429 or 403) or replying instead with a "4xx" HTTP status code (eg. 429 or 403) or
adopt more aggressive policies like dropping connections. adopt more aggressive policies like dropping connections.
Quotas may be enforced on different basis (eg. per user, per IP, per Quotas may be enforced on different basis (eg. per user, per IP, per
geographic area, ..) and at different levels. For example, an user geographic area, ..) and at different levels. For example, an user
may be allowed to issue: may be allowed to issue:
o 10 requests per second; o 10 requests per second;
o limited to 60 request per minute; o limited to 60 requests per minute;
o limited to 1000 request per hour. o limited to 1000 requests per hour.
Moreover system metrics, statistics and heuristics can be used to Moreover system metrics, statistics and heuristics can be used to
implement more complex policies, where the number of acceptable implement more complex policies, where the number of acceptable
request and the time window are computed dynamically. requests and the time window are computed dynamically.
1.2. Current landscape of rate-limiting headers 1.2. Current landscape of rate-limiting headers
To help clients throttling their requests, servers may expose the To help clients throttling their requests, servers may expose the
counters used to evaluate quota policies via HTTP header fields. counters used to evaluate quota policies via HTTP header fields.
Those response headers may be added by HTTP intermediaries such as Those response headers may be added by HTTP intermediaries such as
API gateways and reverse proxies. API gateways and reverse proxies.
On the web we can find many different rate-limit headers, usually On the web we can find many different rate-limit headers, usually
skipping to change at line 220 skipping to change at page 5, line 34
seconds" notation of "Retry-After". seconds" notation of "Retry-After".
The fields definition allows to describe complex policies, including The fields definition allows to describe complex policies, including
the ones using multiple and variable time windows and dynamic quotas, the ones using multiple and variable time windows and dynamic quotas,
or implementing concurrency limits. or implementing concurrency limits.
1.4. Goals 1.4. Goals
The goals of this proposal are: The goals of this proposal are:
1. Standardizing the names and semantics of rate-limit headers to Interoperability: Standardization of the names and semantics of
ease their enforcement and adoption; rate-limit headers to ease their enforcement and adoption;
2. Improve resiliency of HTTP infrastructure by providing clients Resiliency: Improve resiliency of HTTP infrastructure by providing
with information useful to throttle their requests and prevent clients with information useful to throttle their requests and
4xx or 5xx responses; prevent 4xx or 5xx responses;
3. Simplify API documentation by eliminating the need to include Documentation: Simplify API documentation by eliminating the need to
detailed quota limits and related header fields in API include detailed quota limits and related header fields in API
documentation. documentation.
The goals do not include: The goals do not include:
Authorization: The rate-limit fields described here are not meant to Authorization: The rate-limit fields described here are not meant to
support authorization or other kinds of access controls. support authorization or other kinds of access controls.
Throttling scope: This specification does not cover the throttling Throttling scope: This specification does not cover the throttling
scope, that may be the given resource-target, its parent path or scope, that may be the given resource-target, its parent path or
the whole Origin (see Section 7 of [RFC6454]). the whole Origin (see Section 7 of [RFC6454]).
skipping to change at line 270 skipping to change at page 6, line 35
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the Augmented BNF defined in [RFC5234] and updated This document uses the Augmented BNF defined in [RFC5234] and updated
by [RFC7405] along with the "#rule" extension defined in by [RFC7405] along with the "#rule" extension defined in
Section 5.6.1 of [SEMANTICS]. Section 5.6.1 of [SEMANTICS].
The term Origin is to be interpreted as described in Section 7 of The term Origin is to be interpreted as described in Section 7 of
[RFC6454]. [RFC6454].
The "delay-seconds" rule is defined in Section 10.2.4 of [SEMANTICS]. The "delay-seconds" rule is defined in Section 10.2.3 of [SEMANTICS].
2. Expressing rate-limit policies 2. Expressing rate-limit policies
2.1. Time window 2.1. Time window
Rate limit policies limit the number of acceptable requests in a Rate limit policies limit the number of acceptable requests in a
given time window. given time window.
A time window is expressed in seconds, using the following syntax: A time window is expressed in seconds, using the following syntax:
skipping to change at line 524 skipping to change at page 12, line 7
response, and clients need to take this into account. For example, response, and clients need to take this into account. For example,
an implementer concerned with performance might provide "RateLimit" an implementer concerned with performance might provide "RateLimit"
fields only when a given quota is going to expire. fields only when a given quota is going to expire.
Implementers concerned with response fields' size, might take into Implementers concerned with response fields' size, might take into
account their ratio with respect to the payload data, or use header- account their ratio with respect to the payload data, or use header-
compression http features such as [HPACK]. compression http features such as [HPACK].
5. Intermediaries 5. Intermediaries
This section documents the considerations advised in Section 16.3.3 This section documents the considerations advised in Section 16.3.2
of [SEMANTICS]. of [SEMANTICS].
An intermediary that is not part of the originating service An intermediary that is not part of the originating service
infrastructure and is not aware of the quota-policy semantic used by infrastructure and is not aware of the quota-policy semantic used by
the Origin Server SHOULD NOT alter the RateLimit fields' values in the Origin Server SHOULD NOT alter the RateLimit fields' values in
such a way as to communicate a more permissive quota-policy; this such a way as to communicate a more permissive quota-policy; this
includes removing the RateLimit fields. includes removing the RateLimit fields.
An intermediary MAY alter the RateLimit fields in such a way as to An intermediary MAY alter the RateLimit fields in such a way as to
communicate a more restrictive quota-policy when: communicate a more restrictive quota-policy when:
skipping to change at line 890 skipping to change at page 20, line 7
Note that in this last response the client is expected to honor Note that in this last response the client is expected to honor
"Retry-After" and perform no requests for the specified amount of "Retry-After" and perform no requests for the specified amount of
time, whereas the previous example would not force the client to stop time, whereas the previous example would not force the client to stop
requests before the reset time is elapsed, as it would still be free requests before the reset time is elapsed, as it would still be free
to query again the server even if it is likely to have the request to query again the server even if it is likely to have the request
rejected. rejected.
8.3.1. Missing Remaining information 8.3.1. Missing Remaining information
The server does not expose "RateLimit-Remaining" values, but resets The server does not expose "RateLimit-Remaining" values (for example,
the limit counter every second. because the underlying counters are not available). Instead, it
resets the limit counter every second.
It communicates to the client the limit of 10 quota-units per second It communicates to the client the limit of 10 quota-units per second
always returning the couple "RateLimit-Limit" and "RateLimit-Reset". always returning the couple "RateLimit-Limit" and "RateLimit-Reset".
Request: Request:
GET /items/123 HTTP/1.1 GET /items/123 HTTP/1.1
Host: api.example Host: api.example
Response: Response:
skipping to change at line 1126 skipping to change at page 25, line 7
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SEMANTICS] [SEMANTICS]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", draft-ietf-httpbis-semantics-15 (work in Semantics", draft-ietf-httpbis-semantics-19 (work in
progress), March 2021. progress), September 2021.
11.2. Informative References 11.2. Informative References
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
skipping to change at line 1159 skipping to change at page 25, line 40
Stewart, R., Tuexen, M., and P. Lei, "Stream Control Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration", Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012, RFC 6525, DOI 10.17487/RFC6525, February 2012,
<https://www.rfc-editor.org/info/rfc6525>. <https://www.rfc-editor.org/info/rfc6525>.
[UNIX] The Open Group, ., "The Single UNIX Specification, Version [UNIX] The Open Group, ., "The Single UNIX Specification, Version
2 - 6 Vol Set for UNIX 98", February 1997. 2 - 6 Vol Set for UNIX 98", February 1997.
11.3. URIs 11.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-httpapi-wg/ [1] https://mailarchive.ietf.org/arch/browse/httpapi/
[2] https://github.com/ietf-wg-httpapi/ratelimit-headers [2] https://github.com/ietf-wg-httpapi/ratelimit-headers
[3] https://github.com/httpwg/http-core/ [3] https://github.com/httpwg/http-core/
pull/317#issuecomment-585868767 pull/317#issuecomment-585868767
[4] https://github.com/ioggstream/draft-polli-ratelimit-headers/ [4] https://github.com/ioggstream/draft-polli-ratelimit-headers/
issues/70 issues/70
[5] https://community.ntppool.org/t/another-ntp-client-failure- [5] https://community.ntppool.org/t/another-ntp-client-failure-
 End of changes. 17 change blocks. 
77 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/