draft-ietf-httpbis-semantics-15.txt		draft-ietf-httpbis-semantics-latest.txt
	HTTP Working Group R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.		Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
	7538, 7615, 7694 (if approved) Fastly		7538, 7615, 7694 (if approved) Fastly
	Updates: 3864 (if approved) J. Reschke, Ed.		Updates: 3864 (if approved) J. Reschke, Ed.
	Intended status: Standards Track greenbytes		Intended status: Standards Track greenbytes
	Expires: October 1, 2021 March 30, 2021		Expires: October 24, 2021 April 22, 2021
	HTTP Semantics		HTTP Semantics
	draft-ietf-httpbis-semantics-15		draft-ietf-httpbis-semantics-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document describes the overall architecture of HTTP,		systems. This document describes the overall architecture of HTTP,
	establishes common terminology, and defines aspects of the protocol		establishes common terminology, and defines aspects of the protocol
	that are shared by all versions. In this definition are core		that are shared by all versions. In this definition are core
	protocol elements, extensibility mechanisms, and the "http" and		protocol elements, extensibility mechanisms, and the "http" and
	"https" Uniform Resource Identifier (URI) schemes.		"https" Uniform Resource Identifier (URI) schemes.
	This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC		This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
	7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.		7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
			of RFC 7230.
	Editorial Note		Editorial Note
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>.		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information can be found at <https://httpwg.org/>;		Working Group information can be found at <https://httpwg.org/>;
	source code and issues list for this draft can be found at		source code and issues list for this draft can be found at
	<https://github.com/httpwg/http-core>.		<https://github.com/httpwg/http-core>.
	The changes in this draft are summarized in Appendix C.16.		The changes in this draft are summarized in Appendix C.17.
	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 October 1, 2021.		This Internet-Draft will expire on October 24, 2021.
	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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 8, line 51 ¶		skipping to change at page 9, line 7 ¶
	19.1. Normative References . . . . . . . . . . . . . . . . . . 196		19.1. Normative References . . . . . . . . . . . . . . . . . . 196
	19.2. Informative References . . . . . . . . . . . . . . . . . 198		19.2. Informative References . . . . . . . . . . . . . . . . . 198
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 204		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 204
	Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 209		Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 209
	B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 209		B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 209
	B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 209		B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 209
	B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 210		B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 210
	B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 212		B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 212
	B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 212		B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 212
	B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 212		B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 212
	B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 212		B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 213
	B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 213		B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 213
	B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 213		B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 213
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 213		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 213
	C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 213		C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 213
	C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 213		C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 213
	C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 214		C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 214
	C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 215		C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 215
	C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 216		C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 216
	C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 217		C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 217
	C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 217		C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 217
	C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 219		C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 219
	C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 220		C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 220
	C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 221		C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 221
	C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 223		C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 223
	C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 223		C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 223
	C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 224		C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 225
	C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 225		C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 225
	C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 227		C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 227
	C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 227		C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 227
			C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 230
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 230		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 230
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 242		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 242
	1. Introduction		1. Introduction
	1.1. Purpose		1.1. Purpose
	The Hypertext Transfer Protocol (HTTP) is a family of stateless,		The Hypertext Transfer Protocol (HTTP) is a family of stateless,
	application-level, request/response protocols that share a generic		application-level, request/response protocols that share a generic
	interface, extensible semantics, and self-descriptive messages to		interface, extensible semantics, and self-descriptive messages to
	enable flexible interaction with network-based hypertext information		enable flexible interaction with network-based hypertext information
	skipping to change at page 86, line 5 ¶		skipping to change at page 86, line 5 ¶
	determined only while generating the content. For example, some		determined only while generating the content. For example, some
	servers buffer a dynamic response to GET until a minimum amount of		servers buffer a dynamic response to GET until a minimum amount of
	data is generated so that they can more efficiently delimit small		data is generated so that they can more efficiently delimit small
	responses or make late decisions with regard to content selection.		responses or make late decisions with regard to content selection.
	Such a response to GET might contain Content-Length and Vary fields,		Such a response to GET might contain Content-Length and Vary fields,
	for example, that are not generated within a HEAD response. These		for example, that are not generated within a HEAD response. These
	minor inconsistencies are considered preferable to generating and		minor inconsistencies are considered preferable to generating and
	discarding the content for a HEAD request, since HEAD is usually		discarding the content for a HEAD request, since HEAD is usually
	requested for the sake of efficiency.		requested for the sake of efficiency.
	A content within a HEAD request message has no defined semantics;		A client SHOULD NOT generate content in a HEAD request. Content
	sending content in a HEAD request might cause some existing		received in a HEAD request has no defined semantics, cannot alter the
	implementations to reject the request.		meaning or target of the request, and might lead some implementations
			to reject the request and close the connection because of its
			potential as a request smuggling attack (Section 11.2 of
			[Messaging]).
	The response to a HEAD request is cacheable; a cache MAY use it to		The response to a HEAD request is cacheable; a cache MAY use it to
	satisfy subsequent HEAD requests unless otherwise indicated by the		satisfy subsequent HEAD requests unless otherwise indicated by the
	Cache-Control header field (Section 5.2 of [Caching]). A HEAD		Cache-Control header field (Section 5.2 of [Caching]). A HEAD
	response might also affect previously cached responses to GET; see		response might also affect previously cached responses to GET; see
	Section 4.3.5 of [Caching].		Section 4.3.5 of [Caching].
	9.3.3. POST		9.3.3. POST
	The POST method requests that the target resource process the		The POST method requests that the target resource process the
	skipping to change at page 196, line 29 ¶		skipping to change at page 196, line 29 ¶
	+------+-------------------+-------------------------+------+		+------+-------------------+-------------------------+------+
	Table 12		Table 12
	19. References		19. References
	19.1. Normative References		19.1. Normative References
	[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Caching", Work in Progress, Internet-Draft,		Ed., "HTTP Caching", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-cache-latest, March 2021,		draft-ietf-httpbis-cache-latest, April 2021,
	<https://tools.ietf.org/html/draft-ietf-httpbis-cache-		<https://tools.ietf.org/html/draft-ietf-httpbis-cache-
	latest>.		latest>.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/info/rfc793>.		<https://www.rfc-editor.org/info/rfc793>.
	[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950,		Format Specification version 3.3", RFC 1950,
	DOI 10.17487/RFC1950, May 1996,		DOI 10.17487/RFC1950, May 1996,
	skipping to change at page 199, line 44 ¶		skipping to change at page 199, line 44 ¶
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and		[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
	Politics", ACM Transactions on Internet Technology 1(2),		Politics", ACM Transactions on Internet Technology 1(2),
	November 2001, <http://arxiv.org/abs/cs.SE/0105018>.		November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
	[Messaging]		[Messaging]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-		Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
	ietf-httpbis-messaging-latest, March 2021,		ietf-httpbis-messaging-latest, April 2021,
	<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-		<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
	latest>.		latest>.
	[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web		[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
	Applications and Web Services", The Open Web Application		Applications and Web Services", The Open Web Application
	Security Project (OWASP) 2.0.1, July 27, 2005,		Security Project (OWASP) 2.0.1, July 27, 2005,
	<https://www.owasp.org/>.		<https://www.owasp.org/>.
	[REST] Fielding, R.T., "Architectural Styles and the Design of		[REST] Fielding, R.T., "Architectural Styles and the Design of
	Network-based Software Architectures",		Network-based Software Architectures",
	skipping to change at page 202, line 46 ¶		skipping to change at page 202, line 46 ¶
	[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext		[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Conditional Requests",		Transfer Protocol (HTTP/1.1): Conditional Requests",
	RFC 7232, DOI 10.17487/RFC7232, June 2014,		RFC 7232, DOI 10.17487/RFC7232, June 2014,
	<https://www.rfc-editor.org/info/rfc7232>.		<https://www.rfc-editor.org/info/rfc7232>.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,		[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
	RFC 7233, DOI 10.17487/RFC7233, June 2014,		RFC 7233, DOI 10.17487/RFC7233, June 2014,
	<https://www.rfc-editor.org/info/rfc7233>.		<https://www.rfc-editor.org/info/rfc7233>.
			[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
			Ed., "Hypertext Transfer Protocol (HTTP): Caching",
			RFC 7234, DOI 10.17487/RFC7234, June 2014,
			<https://www.rfc-editor.org/info/rfc7234>.
	[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext		[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,		Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
	DOI 10.17487/RFC7235, June 2014,		DOI 10.17487/RFC7235, June 2014,
	<https://www.rfc-editor.org/info/rfc7235>.		<https://www.rfc-editor.org/info/rfc7235>.
	[RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status		[RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status
	Code 308 (Permanent Redirect)", RFC 7538,		Code 308 (Permanent Redirect)", RFC 7538,
	DOI 10.17487/RFC7538, April 2015,		DOI 10.17487/RFC7538, April 2015,
	<https://www.rfc-editor.org/info/rfc7538>.		<https://www.rfc-editor.org/info/rfc7538>.
	skipping to change at page 210, line 46 ¶		skipping to change at page 211, line 4 ¶
	An abstract data type for HTTP messages has been introduced to define		An abstract data type for HTTP messages has been introduced to define
	the components of a message and their semantics as an abstraction		the components of a message and their semantics as an abstraction
	across multiple HTTP versions, rather than in terms of the specific		across multiple HTTP versions, rather than in terms of the specific
	syntax form of HTTP/1.1 in [Messaging], and reflect the contents		syntax form of HTTP/1.1 in [Messaging], and reflect the contents
	after the message is parsed. This makes it easier to distinguish		after the message is parsed. This makes it easier to distinguish
	between requirements on the content (what is conveyed) versus		between requirements on the content (what is conveyed) versus
	requirements on the messaging syntax (how it is conveyed) and avoids		requirements on the messaging syntax (how it is conveyed) and avoids
	baking limitations of early protocol versions into the future of		baking limitations of early protocol versions into the future of
	HTTP. (Section 6)		HTTP. (Section 6)
	The terms "payload" and "payload body" have been replaced with		The terms "payload" and "payload body" have been replaced with
	"content", to better align with its usage elsewhere (e.g., in field		"content", to better align with its usage elsewhere (e.g., in field
	names) and to avoid confusion with frame payloads in HTTP/2 and		names) and to avoid confusion with frame payloads in HTTP/2 and
	HTTP/3. (Section 6.4)		HTTP/3. (Section 6.4)
	The term "effective request URI" has been replaced with "target URI".		The term "effective request URI" has been replaced with "target URI".
	(Section 7.1)		(Section 7.1)
	Restrictions on client retries have been loosened, to reflect		Restrictions on client retries have been loosened, to reflect
	implementation behavior. (Section 9.2.2)		implementation behavior. (Section 9.2.2)
	Clarified that request bodies on GET and DELETE are not		Clarified that request bodies on GET, HEAD, and DELETE are not
	interoperable. (Section 9.3.1, Section 9.3.5)		interoperable. (Section 9.3.1, Section 9.3.2, Section 9.3.5)
	Allowed use of the Content-Range header field (Section 14.4) as a		Allowed use of the Content-Range header field (Section 14.4) as a
	request modifier on PUT. (Section 9.3.4)		request modifier on PUT. (Section 9.3.4)
	Removed a superfluous requirement about setting Content-Length from		Removed a superfluous requirement about setting Content-Length from
	the description of the OPTIONS method. (Section 9.3.7)		the description of the OPTIONS method. (Section 9.3.7)
	Removed normative requirement to use the "message/http" media type in		Removed normative requirement to use the "message/http" media type in
	TRACE responses. (Section 9.3.8)		TRACE responses. (Section 9.3.8)
	skipping to change at page 230, line 5 ¶		skipping to change at page 230, line 15 ¶
	o In Section 10.1.5, note that the Trailer field can be used to		o In Section 10.1.5, note that the Trailer field can be used to
	discover deleted trailers (<https://github.com/httpwg/http-core/		discover deleted trailers (<https://github.com/httpwg/http-core/
	issues/793>)		issues/793>)
	o Throughout, remove unneeded normative references to [Messaging]		o Throughout, remove unneeded normative references to [Messaging]
	(<https://github.com/httpwg/http-core/issues/795>)		(<https://github.com/httpwg/http-core/issues/795>)
	o In Section 10.1.4, explicitly require listing in Connection		o In Section 10.1.4, explicitly require listing in Connection
	(<https://github.com/httpwg/http-core/issues/809>)		(<https://github.com/httpwg/http-core/issues/809>)
			C.17. Since draft-ietf-httpbis-semantics-15
			o In Section 9.3.2, align prose about content in HEAD requests with
			description of GET (<https://github.com/httpwg/http-core/
			issues/826>)
	Acknowledgments		Acknowledgments
	This edition of the HTTP specification builds on the many		Aside from the current editors, the following individuals deserve
	contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616,		special recognition for their contributions to early aspects of HTTP
	and RFC 2818, including substantial contributions made by the current		and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
	and previous editors of HTTP: Tim Berners-Lee, Jean-François Groff,		Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
	Ari Luotonen, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul,		Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
	Larry Masinter, Paul J. Leach, Eric Rescorla, and Yves Lafon.		L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
			D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
			Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
			Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders,
			Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
	In addition, this document has reincorporated the HTTP Authentication		This edition builds on the many contributions that went into past
	Framework, previously defined in RFC 7235 and RFC 2617. We thank		specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC
	John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott		2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC
	D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart		7234, and RFC 7235. The acknowledgements within those documents
	for their work on that specification. See Section 6 of [RFC2617] for		still apply.
	further acknowledgements.
	Since 2014, the following contributors have helped improve the HTTP		Since 2014, the following contributors have helped improve this
	specification by reporting bugs, asking smart questions, drafting or		specification by reporting bugs, asking smart questions, drafting or
	reviewing text, and evaluating open issues:		reviewing text, and evaluating open issues:
	Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders		Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders
	Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron		Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron
	Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright,		Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright,
	Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris		Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris
	Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa,		Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa,
	Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David		Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David
	Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric		Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric
	skipping to change at page 230, line 44 ¶		skipping to change at page 231, line 14 ¶
	Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken		Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken
	Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin		Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin
	Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael		Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael
	Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel		Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel
	J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr		J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr
	Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon		Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon
	Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly,		Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly,
	Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr.,		Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr.,
	Willy Tarreau, Xingwei Liu, and Yishuai Li.		Willy Tarreau, Xingwei Liu, and Yishuai Li.
	See Section 10 of [RFC7230] for further acknowledgements from prior
	revisions.
	Index		Index
	1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X		1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
	1		1
	100 Continue (status code) 15.2.1		100 Continue (status code) 15.2.1
	100-continue (expect value) 10.1.1		100-continue (expect value) 10.1.1
	101 Switching Protocols (status code) 15.2.2		101 Switching Protocols (status code) 15.2.2
	1xx Informational (status code class) 15.2		1xx Informational (status code class) 15.2
	2		2
	200 OK (status code) 15.3.1		200 OK (status code) 15.3.1
End of changes. 22 change blocks.
	33 lines changed or deleted		50 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/