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/