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: January 31, 2022 Red Hat
	May 11, 2021		July 30, 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 January 31, 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 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-17 (work in
	progress), March 2021.		progress), July 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. 9 change blocks.
	64 lines changed or deleted		65 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/