rfc9110v2.xml		rfc9110v3.xml
	skipping to change at line 170 ¶		skipping to change at line 170 ¶
	</section>		</section>
	<section anchor="history.and.evolution" title="History and Evolution">		<section anchor="history.and.evolution" title="History and Evolution">
	<t>		<t>
	HTTP has been the primary information transfer protocol for the World		HTTP has been the primary information transfer protocol for the World
	Wide Web since its introduction in 1990. It began as a trivial		Wide Web since its introduction in 1990. It began as a trivial
	mechanism for low-latency requests, with a single method (GET) to		mechanism for low-latency requests, with a single method (GET) to
	request transfer of a presumed hypertext document identified by a given pathn ame.		request transfer of a presumed hypertext document identified by a given pathn ame.
	As the Web grew, HTTP was extended to enclose requests and responses within		As the Web grew, HTTP was extended to enclose requests and responses within
	messages, transfer arbitrary data formats using MIME-like media types, and		messages, transfer arbitrary data formats using MIME-like media types, and
	route requests through intermediaries. These protocols were eventually		route requests through intermediaries. These protocols were eventually
	defined as HTTP/0.9 and HTTP/1.0 (see <xref target="RFC1945"/>).		defined as HTTP/0.9 and HTTP/1.0 (see <xref target="HTTP10"/>).
	</t>		</t>
	<t>		<t>
	HTTP/1.1 was designed to refine the protocol's features while retaining		HTTP/1.1 was designed to refine the protocol's features while retaining
	compatibility with the existing text-based messaging syntax, improving		compatibility with the existing text-based messaging syntax, improving
	its interoperability, scalability, and robustness across the Internet.		its interoperability, scalability, and robustness across the Internet.
	This included length-based data delimiters for both fixed and dynamic		This included length-based data delimiters for both fixed and dynamic
	(chunked) content, a consistent framework for content negotiation,		(chunked) content, a consistent framework for content negotiation,
	opaque validators for conditional requests, cache controls for better		opaque validators for conditional requests, cache controls for better
	cache consistency, range requests for partial updates, and default		cache consistency, range requests for partial updates, and default
	persistent connections. HTTP/1.1 was introduced in 1995 and published on		persistent connections. HTTP/1.1 was introduced in 1995 and published on
	the Standards Track in 1997 <xref target="RFC2068"/>, revised in		the Standards Track in 1997 <xref target="RFC2068"/>, revised in
	1999 <xref target="RFC2616"/>, and revised again in 2014		1999 <xref target="RFC2616"/>, and revised again in 2014
	(<xref target="RFC7230"/> through <xref target="RFC7235"/>).		(<xref target="RFC7230"/> through <xref target="RFC7235"/>).
	</t>		</t>
	<t>		<t>
	HTTP/2 <xref target="RFC7540"/> introduced a multiplexed session layer		HTTP/2 <xref target="HTTP2"/> introduced a multiplexed session layer
	on top of the existing TLS and TCP protocols for exchanging concurrent		on top of the existing TLS and TCP protocols for exchanging concurrent
	HTTP messages with efficient field compression and server push.		HTTP messages with efficient field compression and server push.
	HTTP/3 <xref target="RFC9113"/> provides greater independence for concurrent		HTTP/3 <xref target="HTTP3"/> provides greater independence for concurrent
	messages by using QUIC as a secure multiplexed transport over UDP instead of		messages by using QUIC as a secure multiplexed transport over UDP instead of
	TCP.		TCP.
	</t>		</t>
	<t>		<t>
	All three major versions of HTTP rely on the semantics defined by		All three major versions of HTTP rely on the semantics defined by
	this document. They have not obsoleted each other because each one has		this document. They have not obsoleted each other because each one has
	specific benefits and limitations depending on the context of use.		specific benefits and limitations depending on the context of use.
	Implementations are expected to choose the most appropriate transport and		Implementations are expected to choose the most appropriate transport and
	messaging syntax for their particular context.		messaging syntax for their particular context.
	</t>		</t>
	<t>		<t>
	This revision of HTTP separates the definition of semantics (this document)		This revision of HTTP separates the definition of semantics (this document)
	and caching <xref target="RFC9111"/> from the current HTTP/1.1 messaging		and caching <xref target="CACHING"/> from the current HTTP/1.1 messaging
	syntax <xref target="RFC9112"/> to allow each major protocol version		syntax <xref target="HTTP11"/> to allow each major protocol version
	to progress independently while referring to the same core semantics.		to progress independently while referring to the same core semantics.
	</t>		</t>
	</section>		</section>
	<section anchor="core.semantics" title="Core Semantics">		<section anchor="core.semantics" title="Core Semantics">
	<t>		<t>
	HTTP provides a uniform interface for interacting with a resource		HTTP provides a uniform interface for interacting with a resource
	(<xref target="resources"/>) -- regardless of its type, nature, or		(<xref target="resources"/>) -- regardless of its type, nature, or
	implementation -- by sending messages that manipulate or transfer		implementation -- by sending messages that manipulate or transfer
	representations (<xref target="representations"/>).		representations (<xref target="representations"/>).
	</t>		</t>
	skipping to change at line 344 ¶		skipping to change at line 344 ¶
	<xref target="changes.from.rfc.7694" format="counter"/>		<xref target="changes.from.rfc.7694" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>		<t>
	[*] This document only obsoletes the portions of		[*] This document only obsoletes the portions of
	<xref target="RFC7230" format="none">RFC 7230</xref> that are independent of		<xref target="RFC7230" format="none">RFC 7230</xref> that are independent of
	the HTTP/1.1 messaging syntax and connection management; the remaining		the HTTP/1.1 messaging syntax and connection management; the remaining
	bits of <xref target="RFC7230" format="none">RFC 7230</xref> are		bits of <xref target="RFC7230" format="none">RFC 7230</xref> are
	obsoleted by "HTTP/1.1" <xref target="RFC9112"/>.		obsoleted by "HTTP/1.1" <xref target="HTTP11"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="conformance" title="Conformance">		<section anchor="conformance" title="Conformance">
	<section anchor="notation" title="Syntax Notation">		<section anchor="notation" title="Syntax Notation">
	<iref primary="true" item="Grammar" subitem="ALPHA"/>		<iref primary="true" item="Grammar" subitem="ALPHA"/>
	<iref primary="true" item="Grammar" subitem="CR"/>		<iref primary="true" item="Grammar" subitem="CR"/>
	<iref primary="true" item="Grammar" subitem="CRLF"/>		<iref primary="true" item="Grammar" subitem="CRLF"/>
	<iref primary="true" item="Grammar" subitem="CTL"/>		<iref primary="true" item="Grammar" subitem="CTL"/>
	<iref primary="true" item="Grammar" subitem="DIGIT"/>		<iref primary="true" item="Grammar" subitem="DIGIT"/>
	skipping to change at line 540 ¶		skipping to change at line 540 ¶
	HTTP version number changes when incompatible changes are made to the wire		HTTP version number changes when incompatible changes are made to the wire
	format. Additionally, HTTP allows incremental, backwards-compatible		format. Additionally, HTTP allows incremental, backwards-compatible
	changes to be made to the protocol without changing its version through		changes to be made to the protocol without changing its version through
	the use of defined extension points (<xref target="extending"/>).		the use of defined extension points (<xref target="extending"/>).
	</t>		</t>
	<t>		<t>
	The protocol version as a whole indicates the sender's conformance with		The protocol version as a whole indicates the sender's conformance with
	the set of requirements laid out in that version's corresponding		the set of requirements laid out in that version's corresponding
	specification of HTTP.		specification of HTTP.
	For example, the version "HTTP/1.1" is defined by the combined		For example, the version "HTTP/1.1" is defined by the combined
	specifications of this document, "HTTP Caching" <xref target="RFC9111"/>,		specifications of this document, "HTTP Caching" <xref target="CACHING"/>,
	and "HTTP/1.1" <xref target="RFC9112"/>.		and "HTTP/1.1" <xref target="HTTP11"/>.
	</t>		</t>
	<t>		<t>
	HTTP's major version number is incremented when an incompatible message		HTTP's major version number is incremented when an incompatible message
	syntax is introduced. The minor number is incremented when changes made to		syntax is introduced. The minor number is incremented when changes made to
	the protocol have the effect of adding to the message semantics or		the protocol have the effect of adding to the message semantics or
	implying additional capabilities of the sender.		implying additional capabilities of the sender.
	</t>		</t>
	<t>		<t>
	The minor version advertises the sender's communication capabilities even		The minor version advertises the sender's communication capabilities even
	when the sender is only using a backwards-compatible subset of the		when the sender is only using a backwards-compatible subset of the
	skipping to change at line 591 ¶		skipping to change at line 591 ¶
	semantics in the request method (<xref target="methods"/>) and a few		semantics in the request method (<xref target="methods"/>) and a few
	request-modifying header fields.		request-modifying header fields.
	A resource cannot treat a request in a manner inconsistent with the		A resource cannot treat a request in a manner inconsistent with the
	semantics of the method of the request. For example, though the URI of a		semantics of the method of the request. For example, though the URI of a
	resource might imply semantics that are not safe, a client can expect the		resource might imply semantics that are not safe, a client can expect the
	resource to avoid actions that are unsafe when processing a request with a		resource to avoid actions that are unsafe when processing a request with a
	safe method (see <xref target="safe.methods"/>).		safe method (see <xref target="safe.methods"/>).
	</t>		</t>
	<t>		<t>
	HTTP relies upon the Uniform Resource Identifier (URI)		HTTP relies upon the Uniform Resource Identifier (URI)
	standard <xref target="RFC3986"/> to indicate the target resource		standard <xref target="URI"/> to indicate the target resource
	(<xref target="target.resource"/>) and relationships between resources.		(<xref target="target.resource"/>) and relationships between resources.
	</t>		</t>
	</section>		</section>
	<section anchor="representations" title="Representations">		<section anchor="representations" title="Representations">
	<iref primary="true" item="representation"/>		<iref primary="true" item="representation"/>
	<t>		<t>
	A <em>representation</em> is information		A <em>representation</em> is information
	that is intended to reflect a past, current, or desired state of a given		that is intended to reflect a past, current, or desired state of a given
	resource, in a format that can be readily communicated via the protocol.		resource, in a format that can be readily communicated via the protocol.
	A representation consists of a set of representation metadata and a		A representation consists of a set of representation metadata and a
	skipping to change at line 870 ¶		skipping to change at line 870 ¶
	to user agent requirements on the gateway's inbound connection.		to user agent requirements on the gateway's inbound connection.
	</t>		</t>
	<t>		<t>
	<iref primary="true" item="tunnel"/>		<iref primary="true" item="tunnel"/>
	A <em>tunnel</em> acts as a blind relay between two connections		A <em>tunnel</em> acts as a blind relay between two connections
	without changing the messages. Once active, a tunnel is not		without changing the messages. Once active, a tunnel is not
	considered a party to the HTTP communication, though the tunnel might		considered a party to the HTTP communication, though the tunnel might
	have been initiated by an HTTP request. A tunnel ceases to exist when		have been initiated by an HTTP request. A tunnel ceases to exist when
	both ends of the relayed connection are closed. Tunnels are used to		both ends of the relayed connection are closed. Tunnels are used to
	extend a virtual connection through an intermediary, such as when		extend a virtual connection through an intermediary, such as when
	Transport Layer Security (TLS, <xref target="RFC8446"/>) is used to		Transport Layer Security (TLS, <xref target="TLS13"/>) is used to
	establish confidential communication through a shared firewall proxy.		establish confidential communication through a shared firewall proxy.
	</t>		</t>
	<t>		<t>
	The above categories for intermediary only consider those acting as		The above categories for intermediary only consider those acting as
	participants in the HTTP communication. There are also intermediaries		participants in the HTTP communication. There are also intermediaries
	that can act on lower layers of the network protocol stack, filtering or		that can act on lower layers of the network protocol stack, filtering or
	redirecting HTTP traffic without the knowledge or permission of message		redirecting HTTP traffic without the knowledge or permission of message
	senders. Network intermediaries are indistinguishable (at a protocol level)		senders. Network intermediaries are indistinguishable (at a protocol level)
	from an on-path attacker, often introducing security flaws or		from an on-path attacker, often introducing security flaws or
	interoperability problems due to mistakenly violating HTTP semantics.		interoperability problems due to mistakenly violating HTTP semantics.
	skipping to change at line 932 ¶		skipping to change at line 932 ¶
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>		<t>
	<iref primary="true" item="cacheable"/>		<iref primary="true" item="cacheable"/>
	A response is <em>cacheable</em> if a cache is allowed to store a copy of		A response is <em>cacheable</em> if a cache is allowed to store a copy of
	the response message for use in answering subsequent requests.		the response message for use in answering subsequent requests.
	Even when a response is cacheable, there might be additional		Even when a response is cacheable, there might be additional
	constraints placed by the client or by the origin server on when		constraints placed by the client or by the origin server on when
	that cached response can be used for a particular request. HTTP		that cached response can be used for a particular request. HTTP
	requirements for cache behavior and cacheable responses are		requirements for cache behavior and cacheable responses are
	defined in <xref target="RFC9111"/>.		defined in <xref target="CACHING"/>.
	</t>		</t>
	<t>		<t>
	There is a wide variety of architectures and configurations		There is a wide variety of architectures and configurations
	of caches deployed across the World Wide Web and		of caches deployed across the World Wide Web and
	inside large organizations. These include national hierarchies		inside large organizations. These include national hierarchies
	of proxy caches to save bandwidth and reduce latency, content delivery		of proxy caches to save bandwidth and reduce latency, content delivery
	networks that use gateway caching to optimize regional and global distributio n of popular sites,		networks that use gateway caching to optimize regional and global distributio n of popular sites,
	collaborative systems that		collaborative systems that
	broadcast or multicast cache entries, archives of pre-fetched cache		broadcast or multicast cache entries, archives of pre-fetched cache
	entries for use in off-line or high-latency environments, and so on.		entries for use in off-line or high-latency environments, and so on.
	skipping to change at line 981 ¶		skipping to change at line 981 ¶
	Content-Type: text/plain		Content-Type: text/plain
	Hello World! My content includes a trailing CRLF.		Hello World! My content includes a trailing CRLF.
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="uri" title="Identifiers in HTTP">		<section anchor="uri" title="Identifiers in HTTP">
	<iref primary="true" item="URI"/>		<iref primary="true" item="URI"/>
	<iref primary="false" item="resource"/>		<iref primary="false" item="resource"/>
	<t>		<t>
	Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used		Uniform Resource Identifiers (URIs) <xref target="URI"/> are used
	throughout HTTP as the means for identifying resources (<xref target="resourc es"/>).		throughout HTTP as the means for identifying resources (<xref target="resourc es"/>).
	</t>		</t>
	<section anchor="uri.references" title="URI References">		<section anchor="uri.references" title="URI References">
	<iref primary="true" item="URI reference"/>		<iref primary="true" item="URI reference"/>
	<t>		<t>
	URI references are used to target requests, indicate redirects, and define		URI references are used to target requests, indicate redirects, and define
	relationships.		relationships.
	</t>		</t>
	<t>		<t>
	The definitions of "URI-reference",		The definitions of "URI-reference",
	skipping to change at line 1120 ¶		skipping to change at line 1120 ¶
	whether or not that server currently maps that identifier to a resource.		whether or not that server currently maps that identifier to a resource.
	The delegated nature of registered names and IP addresses creates a		The delegated nature of registered names and IP addresses creates a
	federated namespace whether or not an HTTP server is present.		federated namespace whether or not an HTTP server is present.
	</t>		</t>
	<section anchor="http.uri" title="http URI Scheme">		<section anchor="http.uri" title="http URI Scheme">
	<iref item="http URI scheme" primary="true"/>		<iref item="http URI scheme" primary="true"/>
	<iref item="URI scheme" subitem="http" primary="true"/>		<iref item="URI scheme" subitem="http" primary="true"/>
	<t>		<t>
	The "http" URI scheme is hereby defined for minting identifiers within the		The "http" URI scheme is hereby defined for minting identifiers within the
	hierarchical namespace governed by a potential HTTP origin server		hierarchical namespace governed by a potential HTTP origin server
	listening for TCP <xref target="RFC0793"/> connections on a given port.		listening for TCP <xref target="TCP"/> connections on a given port.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="http-URI"/>		<iref primary="true" item="Grammar" subitem="http-URI"/>
	<sourcecode type="abnf7230"><![CDATA[ http-URI = "http" "://" au thority path-abempty [ "?" query ]		<sourcecode type="abnf7230"><![CDATA[ http-URI = "http" "://" au thority path-abempty [ "?" query ]
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The origin server for an "http" URI is identified by the		The origin server for an "http" URI is identified by the
	<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier		<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier
	(<xref target="RFC3986" sectionFormat="comma" section="3.2.2"/>)		(<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
	and optional port number (<xref target="RFC3986" sectionFormat="comma" sectio		and optional port number (<xref target="URI" sectionFormat="comma" section="3
	n="3.2.3"/>).		.2.3"/>).
	If the port subcomponent is empty or not given, TCP port 80 (the		If the port subcomponent is empty or not given, TCP port 80 (the
	reserved port for WWW services) is the default.		reserved port for WWW services) is the default.
	The origin determines who has the right to respond authoritatively to		The origin determines who has the right to respond authoritatively to
	requests that target the identified resource, as defined in		requests that target the identified resource, as defined in
	<xref target="http.origin"/>.		<xref target="http.origin"/>.
	</t>		</t>
	<t>		<t>
	A sender <bcp14>MUST NOT</bcp14> generate an "http" URI with an empty host id entifier.		A sender <bcp14>MUST NOT</bcp14> generate an "http" URI with an empty host id entifier.
	A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.		A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.
	</t>		</t>
	skipping to change at line 1154 ¶		skipping to change at line 1154 ¶
	</t>		</t>
	</section>		</section>
	<section anchor="https.uri" title="https URI Scheme">		<section anchor="https.uri" title="https URI Scheme">
	<iref item="https URI scheme" primary="true"/>		<iref item="https URI scheme" primary="true"/>
	<iref item="URI scheme" subitem="https" primary="true"/>		<iref item="URI scheme" subitem="https" primary="true"/>
	<iref item="secured" primary="true"/>		<iref item="secured" primary="true"/>
	<t>		<t>
	The "https" URI scheme is hereby defined for minting identifiers within the		The "https" URI scheme is hereby defined for minting identifiers within the
	hierarchical namespace governed by a potential origin server listening for		hierarchical namespace governed by a potential origin server listening for
	TCP connections on a given port and capable of establishing a TLS		TCP connections on a given port and capable of establishing a TLS
	<xref target="RFC8446"/> connection that has been secured for HTTP		<xref target="TLS13"/> connection that has been secured for HTTP
	communication. In this context, <em>secured</em> specifically		communication. In this context, <em>secured</em> specifically
	means that the server has been authenticated as acting on behalf of the		means that the server has been authenticated as acting on behalf of the
	identified authority and all HTTP communication with that server has		identified authority and all HTTP communication with that server has
	confidentiality and integrity protection that is acceptable to both client		confidentiality and integrity protection that is acceptable to both client
	and server.		and server.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="https-URI"/>		<iref primary="true" item="Grammar" subitem="https-URI"/>
	<sourcecode type="abnf7230"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ]		<sourcecode type="abnf7230"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ]
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The origin server for an "https" URI is identified by the		The origin server for an "https" URI is identified by the
	<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier		<xref target="uri.references" format="none">authority</xref> component, which includes a host identifier
	(<xref target="RFC3986" sectionFormat="comma" section="3.2.2"/>)		(<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
	and optional port number (<xref target="RFC3986" sectionFormat="comma" sectio		and optional port number (<xref target="URI" sectionFormat="comma" section="3
	n="3.2.3"/>).		.2.3"/>).
	If the port subcomponent is empty or not given, TCP port 443		If the port subcomponent is empty or not given, TCP port 443
	(the reserved port for HTTP over TLS) is the default.		(the reserved port for HTTP over TLS) is the default.
	The origin determines who has the right to respond authoritatively to		The origin determines who has the right to respond authoritatively to
	requests that target the identified resource, as defined in		requests that target the identified resource, as defined in
	<xref target="https.origin"/>.		<xref target="https.origin"/>.
	</t>		</t>
	<t>		<t>
	A sender <bcp14>MUST NOT</bcp14> generate an "https" URI with an empty host i dentifier.		A sender <bcp14>MUST NOT</bcp14> generate an "https" URI with an empty host i dentifier.
	A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.		A recipient that processes such a URI reference <bcp14>MUST</bcp14> reject it as invalid.
	</t>		</t>
	skipping to change at line 1195 ¶		skipping to change at line 1195 ¶
	A client <bcp14>MUST</bcp14> ensure that its HTTP requests for an "https" res ource are		A client <bcp14>MUST</bcp14> ensure that its HTTP requests for an "https" res ource are
	secured, prior to being communicated, and that it only accepts secured		secured, prior to being communicated, and that it only accepts secured
	responses to those requests. Note that the definition of what cryptographic		responses to those requests. Note that the definition of what cryptographic
	mechanisms are acceptable to client and server are usually negotiated and		mechanisms are acceptable to client and server are usually negotiated and
	can change over time.		can change over time.
	</t>		</t>
	<t>		<t>
	Resources made available via the "https" scheme have no shared identity		Resources made available via the "https" scheme have no shared identity
	with the "http" scheme. They are distinct origins with separate namespaces.		with the "http" scheme. They are distinct origins with separate namespaces.
	However, extensions to HTTP that are defined as applying to all origins with		However, extensions to HTTP that are defined as applying to all origins with
	the same host, such as the Cookie protocol <xref target="RFC6265"/>,		the same host, such as the Cookie protocol <xref target="COOKIE"/>,
	allow information set by one service to impact communication with other		allow information set by one service to impact communication with other
	services within a matching group of host domains. Such extensions ought to		services within a matching group of host domains. Such extensions ought to
	be designed with great care to prevent information obtained from a secured		be designed with great care to prevent information obtained from a secured
	connection being inadvertently exchanged within an unsecured context.		connection being inadvertently exchanged within an unsecured context.
	</t>		</t>
	</section>		</section>
	<section anchor="uri.comparison" title="http(s) Normalization and Co mparison">		<section anchor="uri.comparison" title="http(s) Normalization and Co mparison">
	<t>		<t>
	The "http" and "https" URI are normalized and compared according to the		The "http" and "https" URI are normalized and compared according to the
	methods defined in <xref target="RFC3986" section="6"/>, using		methods defined in <xref target="URI" section="6"/>, using
	the defaults described above for each scheme.		the defaults described above for each scheme.
	</t>		</t>
	<t>		<t>
	HTTP does not require the use of a specific method for determining		HTTP does not require the use of a specific method for determining
	equivalence. For example, a cache key might be compared as a simple		equivalence. For example, a cache key might be compared as a simple
	string, after syntax-based normalization, or after scheme-based		string, after syntax-based normalization, or after scheme-based
	normalization.		normalization.
	</t>		</t>
	<t>		<t>
	Scheme-based normalization (<xref target="RFC3986" section="6.2.3"/>) of "htt p" and "https" URIs involves the following		Scheme-based normalization (<xref target="URI" section="6.2.3"/>) of "http" a nd "https" URIs involves the following
	additional rules:		additional rules:
	</t>		</t>
	<ul>		<ul>
	<li>If the port is equal to the default port for a scheme, the normal form		<li>If the port is equal to the default port for a scheme, the normal form
	is to omit the port subcomponent.</li>		is to omit the port subcomponent.</li>
	<li>When not being used as the target of an OPTIONS request, a n empty path		<li>When not being used as the target of an OPTIONS request, a n empty path
	component is equivalent to an absolute path of "/", so the normal form is		component is equivalent to an absolute path of "/", so the normal form is
	to provide a path of "/" instead.</li>		to provide a path of "/" instead.</li>
	<li>The scheme and host are case-insensitive and normally prov ided in		<li>The scheme and host are case-insensitive and normally prov ided in
	lowercase; all other components are compared in a case-sensitive		lowercase; all other components are compared in a case-sensitive
	skipping to change at line 1243 ¶		skipping to change at line 1243 ¶
	to their percent-encoded octets: the normal form is to not encode		to their percent-encoded octets: the normal form is to not encode
	them (see Sections 2.1 and 2.2 of [URI]).		them (see Sections 2.1 and 2.2 of [URI]).
	Perhaps:		Perhaps:
	* Characters other than those in the "reserved" set are equivalent		* Characters other than those in the "reserved" set are equivalent
	to their percent-encoded octets: the normal form is not encoded		to their percent-encoded octets: the normal form is not encoded
	(see Sections 2.1 and 2.2 of [URI]).		(see Sections 2.1 and 2.2 of [URI]).
	-->		-->
	<li>Characters other than those in the "reserved" set are equi valent to		<li>Characters other than those in the "reserved" set are equi valent to
	their percent-encoded octets: the normal form is to not encode them (see		their percent-encoded octets: the normal form is to not encode them (see
	Sections <xref target="RFC3986" sectionFormat="bare" section="2.1"/> and <xre f target="RFC3986" sectionFormat="bare" section="2.2"/> of <xref target="RFC3986 "/>).</li>		Sections <xref target="URI" sectionFormat="bare" section="2.1"/> and <xref ta rget="URI" sectionFormat="bare" section="2.2"/> of <xref target="URI"/>).</li>
	</ul>		</ul>
	<t>		<t>
	For example, the following three URIs are equivalent:		For example, the following three URIs are equivalent:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork type="example"><![CDATA[
	http://example.com:80/~smith/home.html		http://example.com:80/~smith/home.html
	http://EXAMPLE.com/%7Esmith/home.html		http://EXAMPLE.com/%7Esmith/home.html
	http://EXAMPLE.com:/%7esmith/home.html		http://EXAMPLE.com:/%7esmith/home.html
	]]></artwork>		]]></artwork>
	<t>		<t>
	Two HTTP URIs that are equivalent after normalization (using any method)		Two HTTP URIs that are equivalent after normalization (using any method)
	can be assumed to identify the same resource, and any HTTP component <bcp14>M AY</bcp14>		can be assumed to identify the same resource, and any HTTP component <bcp14>M AY</bcp14>
	perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp 14> be		perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp 14> be
	identified by HTTP URIs that are equivalent after normalization (using any		identified by HTTP URIs that are equivalent after normalization (using any
	method defined in <xref target="RFC3986" section="6.2"/>).		method defined in <xref target="URI" section="6.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="http.userinfo" title="Deprecation of userinfo in ht tp(s) URIs">		<section anchor="http.userinfo" title="Deprecation of userinfo in ht tp(s) URIs">
	<t>		<t>
	The URI generic syntax for authority also includes a userinfo subcomponent		The URI generic syntax for authority also includes a userinfo subcomponent
	(<xref target="RFC3986" sectionFormat="comma" section="3.2.1"/>) for includin g user		(<xref target="URI" sectionFormat="comma" section="3.2.1"/>) for including us er
	authentication information in the URI. In that subcomponent, the		authentication information in the URI. In that subcomponent, the
	use of the format "user:password" is deprecated.		use of the format "user:password" is deprecated.
	</t>		</t>
	<t>		<t>
	Some implementations make use of the userinfo component for internal		Some implementations make use of the userinfo component for internal
	configuration of authentication information, such as within command		configuration of authentication information, such as within command
	invocation options, configuration files, or bookmark lists, even		invocation options, configuration files, or bookmark lists, even
	though such usage might expose a user identifier or password.		though such usage might expose a user identifier or password.
	</t>		</t>
	<t>		<t>
	skipping to change at line 1292 ¶		skipping to change at line 1292 ¶
	an error; it is likely being used to obscure the authority for the sake of		an error; it is likely being used to obscure the authority for the sake of
	phishing attacks.		phishing attacks.
	</t>		</t>
	</section>		</section>
	<section anchor="uri.fragment.identifiers"		<section anchor="uri.fragment.identifiers"
	title="http(s) References with Fragment Identifiers">		title="http(s) References with Fragment Identifiers">
	<iref item="Fragment Identifiers"/>		<iref item="Fragment Identifiers"/>
	<t>		<t>
	Fragment identifiers allow for indirect identification		Fragment identifiers allow for indirect identification
	of a secondary resource, independent of the URI scheme, as defined in		of a secondary resource, independent of the URI scheme, as defined in
	<xref target="RFC3986" section="3.5"/>.		<xref target="URI" section="3.5"/>.
	Some protocol elements that refer to a URI allow inclusion of a fragment,		Some protocol elements that refer to a URI allow inclusion of a fragment,
	while others do not. They are distinguished by use of the ABNF rule for		while others do not. They are distinguished by use of the ABNF rule for
	elements where fragment is allowed; otherwise, a specific rule that excludes		elements where fragment is allowed; otherwise, a specific rule that excludes
	fragments is used.		fragments is used.
	</t>		</t>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> The fragment identifier component is not part of the scheme		<strong>Note:</strong> The fragment identifier component is not part of the scheme
	definition for a URI scheme (see <xref target="RFC3986" section="4.3"/>),		definition for a URI scheme (see <xref target="URI" section="4.3"/>),
	thus does not appear in the ABNF definitions for the "http" and "https"		thus does not appear in the ABNF definitions for the "http" and "https"
	URI schemes above.		URI schemes above.
	</t>		</t>
	</aside>		</aside>
	</section>		</section>
	</section>		</section>
	<section anchor="authoritative.access" title="Authoritative Access">		<section anchor="authoritative.access" title="Authoritative Access">
	<t>		<t>
	Authoritative access refers to dereferencing a given identifier,		Authoritative access refers to dereferencing a given identifier,
	for the sake of access to the identified resource, in a way that the client		for the sake of access to the identified resource, in a way that the client
	skipping to change at line 1407 ¶		skipping to change at line 1407 ¶
	target URI (<xref target="target.resource"/>).		target URI (<xref target="target.resource"/>).
	</t>		</t>
	<t>		<t>
	If the server responds to such a request with a non-interim HTTP response		If the server responds to such a request with a non-interim HTTP response
	message, as described in <xref target="status.codes"/>, then that response		message, as described in <xref target="status.codes"/>, then that response
	is considered an authoritative answer to the client's request.		is considered an authoritative answer to the client's request.
	</t>		</t>
	<t>		<t>
	Note, however, that the above is not the only means for obtaining an		Note, however, that the above is not the only means for obtaining an
	authoritative response, nor does it imply that an authoritative response		authoritative response, nor does it imply that an authoritative response
	is always necessary (see <xref target="RFC9111"/>).		is always necessary (see <xref target="CACHING"/>).
	For example, the Alt-Svc header field <xref target="RFC7838"/> allows an		For example, the Alt-Svc header field <xref target="ALTSVC"/> allows an
	origin server to identify other services that are also authoritative for		origin server to identify other services that are also authoritative for
	that origin. Access to "http" identified resources might also be provided		that origin. Access to "http" identified resources might also be provided
	by protocols outside the scope of this document.		by protocols outside the scope of this document.
	</t>		</t>
	</section>		</section>
	<section anchor="https.origin" title="https Origins">		<section anchor="https.origin" title="https Origins">
	<t>		<t>
	The "https" scheme (<xref target="https.uri"/>) associates authority based		The "https" scheme (<xref target="https.uri"/>) associates authority based
	on the ability of a server to use the private key corresponding to a		on the ability of a server to use the private key corresponding to a
	certificate that the client considers to be trustworthy for the identified		certificate that the client considers to be trustworthy for the identified
	skipping to change at line 1486 ¶		skipping to change at line 1486 ¶
	(<xref target="target.resource"/>).		(<xref target="target.resource"/>).
	</t>		</t>
	<t>		<t>
	If the server responds to such a request with a non-interim HTTP response		If the server responds to such a request with a non-interim HTTP response
	message, as described in <xref target="status.codes"/>, then that response		message, as described in <xref target="status.codes"/>, then that response
	is considered an authoritative answer to the client's request.		is considered an authoritative answer to the client's request.
	</t>		</t>
	<t>		<t>
	Note, however, that the above is not the only means for obtaining an		Note, however, that the above is not the only means for obtaining an
	authoritative response, nor does it imply that an authoritative response		authoritative response, nor does it imply that an authoritative response
	is always necessary (see <xref target="RFC9111"/>).		is always necessary (see <xref target="CACHING"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="https.verify" title="https Certificate Verification ">		<section anchor="https.verify" title="https Certificate Verification ">
	<t>		<t>
	To establish a <xref target="https.uri" format="none">secured</xref> connecti on to dereference a URI,		To establish a <xref target="https.uri" format="none">secured</xref> connecti on to dereference a URI,
	a client <bcp14>MUST</bcp14> verify that the service's identity is an accepta ble		a client <bcp14>MUST</bcp14> verify that the service's identity is an accepta ble
	match for the URI's origin server. Certificate verification is used to		match for the URI's origin server. Certificate verification is used to
	prevent server impersonation by an on-path attacker or by an attacker		prevent server impersonation by an on-path attacker or by an attacker
	that controls name resolution. This process requires that a client be		that controls name resolution. This process requires that a client be
	configured with a set of trust anchors.		configured with a set of trust anchors.
	skipping to change at line 1541 ¶		skipping to change at line 1541 ¶
	Automated clients <bcp14>MAY</bcp14> provide a configuration setting that dis ables		Automated clients <bcp14>MAY</bcp14> provide a configuration setting that dis ables
	this check, but <bcp14>MUST</bcp14> provide a setting which enables it.		this check, but <bcp14>MUST</bcp14> provide a setting which enables it.
	</t>		</t>
	</section>		</section>
	<section anchor="https.ip-id" title="IP-ID Reference Identity">		<section anchor="https.ip-id" title="IP-ID Reference Identity">
	<t>		<t>
	A server that is identified using an IP address literal in the "host" field		A server that is identified using an IP address literal in the "host" field
	of an "https" URI has a reference identity of type IP-ID. An IP version 4		of an "https" URI has a reference identity of type IP-ID. An IP version 4
	address uses the "IPv4address" ABNF rule, and an IP version 6 address uses		address uses the "IPv4address" ABNF rule, and an IP version 6 address uses
	the "IP-literal" production with the "IPv6address" option; see		the "IP-literal" production with the "IPv6address" option; see
	<xref target="RFC3986" section="3.2.2"/>. A reference identity of		<xref target="URI" section="3.2.2"/>. A reference identity of
	IP-ID contains the decoded bytes of the IP address.		IP-ID contains the decoded bytes of the IP address.
	</t>		</t>
	<t>		<t>
	An IP version 4 address is 4 octets, and an IP version 6 address is 16 octets .		An IP version 4 address is 4 octets, and an IP version 6 address is 16 octets .
	Use of IP-ID is not defined for any other IP version. The iPAddress		Use of IP-ID is not defined for any other IP version. The iPAddress
	choice in the certificate subjectAltName extension does not explicitly		choice in the certificate subjectAltName extension does not explicitly
	include the IP version and so relies on the length of the address to		include the IP version and so relies on the length of the address to
	distinguish versions; see		distinguish versions; see
	<xref target="RFC5280" section="4.2.1.6"/>.		<xref target="RFC5280" section="4.2.1.6"/>.
	</t>		</t>
	skipping to change at line 1665 ¶		skipping to change at line 1665 ¶
	<bcp14>MUST NOT</bcp14> generate multiple field lines with the same name in a message		<bcp14>MUST NOT</bcp14> generate multiple field lines with the same name in a message
	(whether in the headers or trailers) or append a field line when a field		(whether in the headers or trailers) or append a field line when a field
	line of the same name already exists in the message, unless that field's		line of the same name already exists in the message, unless that field's
	definition allows multiple field line values to be recombined as a		definition allows multiple field line values to be recombined as a
	comma-separated list (i.e., at least one alternative of the field's		comma-separated list (i.e., at least one alternative of the field's
	definition allows a comma-separated list, such as an ABNF rule of		definition allows a comma-separated list, such as an ABNF rule of
	#(values) defined in <xref target="abnf.extension"/>).		#(values) defined in <xref target="abnf.extension"/>).
	</t>		</t>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> In practice, the "Set-Cookie" header fi eld <xref target="RFC6265"/>		<strong>Note:</strong> In practice, the "Set-Cookie" header fi eld <xref target="COOKIE"/>
	often appears in a response message across multiple field lines and does not		often appears in a response message across multiple field lines and does not
	use the list syntax, violating the above requirements on multiple field lines		use the list syntax, violating the above requirements on multiple field lines
	with the same field name. Since it cannot be combined into a single field		with the same field name. Since it cannot be combined into a single field
	value, recipients ought to handle "Set-Cookie" as a special case while		value, recipients ought to handle "Set-Cookie" as a special case while
	processing fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for		processing fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for
	details.)		details.)
	</t>		</t>
	</aside>		</aside>
	<t>		<t>
	The order in which field lines with differing field names are received in a		The order in which field lines with differing field names are received in a
	skipping to change at line 1702 ¶		skipping to change at line 1702 ¶
	or on the length of a header or trailer section as a whole, as described in		or on the length of a header or trailer section as a whole, as described in
	<xref target="conformance"/>. Various ad hoc limitations on individual		<xref target="conformance"/>. Various ad hoc limitations on individual
	lengths are found in practice, often depending on the specific		lengths are found in practice, often depending on the specific
	field's semantics.		field's semantics.
	</t>		</t>
	<t>		<t>
	A server that receives a request header field line, field value, or set of		A server that receives a request header field line, field value, or set of
	fields larger than it wishes to process <bcp14>MUST</bcp14> respond with an a ppropriate		fields larger than it wishes to process <bcp14>MUST</bcp14> respond with an a ppropriate
	<xref target="status.4xx" format="none">4xx (Client Error)</xref> status code . Ignoring such header fields		<xref target="status.4xx" format="none">4xx (Client Error)</xref> status code . Ignoring such header fields
	would increase the server's vulnerability to request smuggling attacks		would increase the server's vulnerability to request smuggling attacks
	(<xref target="RFC9112" section="11.2"/>).		(<xref target="HTTP11" section="11.2"/>).
	</t>		</t>
	<t>		<t>
	A client <bcp14>MAY</bcp14> discard or truncate received field lines that are larger		A client <bcp14>MAY</bcp14> discard or truncate received field lines that are larger
	than the client wishes to process if the field semantics are such that the		than the client wishes to process if the field semantics are such that the
	dropped value(s) can be safely ignored without changing the		dropped value(s) can be safely ignored without changing the
	message framing or response semantics.		message framing or response semantics.
	</t>		</t>
	</section>		</section>
	<section anchor="fields.values" title="Field Values">		<section anchor="fields.values" title="Field Values">
	<t>		<t>
	skipping to change at line 2165 ¶		skipping to change at line 2165 ¶
	day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"		day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
	/ %s"Thursday" / %s"Friday" / %s"Saturday"		/ %s"Thursday" / %s"Friday" / %s"Saturday"
	/ %s"Sunday"		/ %s"Sunday"
	]]></sourcecode>		]]></sourcecode>
	<iref primary="true" item="Grammar" subitem="asctime-date"/>		<iref primary="true" item="Grammar" subitem="asctime-date"/>
	<sourcecode type="abnf7230"><![CDATA[ asctime-date = day-name SP date3 SP time-of-day SP year		<sourcecode type="abnf7230"><![CDATA[ asctime-date = day-name SP date3 SP time-of-day SP year
	date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))		date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
	; e.g., Jun 2		; e.g., Jun 2
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	HTTP-date is case sensitive. Note that <xref target="RFC9111" section="4.2"/> relaxes this for cache recipients.		HTTP-date is case sensitive. Note that <xref target="CACHING" section="4.2"/> relaxes this for cache recipients.
	</t>		</t>
	<t>		<t>
	A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-da te beyond		A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-da te beyond
	that specifically included as SP in the grammar.		that specifically included as SP in the grammar.
	The semantics of <xref target="preferred.date.format" format="none">day-name< /xref>, <xref target="preferred.date.format" format="none">day</xref>,		The semantics of <xref target="preferred.date.format" format="none">day-name< /xref>, <xref target="preferred.date.format" format="none">day</xref>,
	<xref target="preferred.date.format" format="none">month</xref>, <xref target ="preferred.date.format" format="none">year</xref>, and <xref target="preferred. date.format" format="none">time-of-day</xref>		<xref target="preferred.date.format" format="none">month</xref>, <xref target ="preferred.date.format" format="none">year</xref>, and <xref target="preferred. date.format" format="none">time-of-day</xref>
	are the same as those defined for the Internet Message Format constructs		are the same as those defined for the Internet Message Format constructs
	with the corresponding name (<xref target="RFC5322" sectionFormat="comma" sec tion="3.3"/>).		with the corresponding name (<xref target="RFC5322" sectionFormat="comma" sec tion="3.3"/>).
	</t>		</t>
	<t>		<t>
	skipping to change at line 2315 ¶		skipping to change at line 2315 ¶
	<iref primary="true" item="control data"/>		<iref primary="true" item="control data"/>
	<t>		<t>
	Messages start with control data that describe its primary purpose. Request		Messages start with control data that describe its primary purpose. Request
	message control data includes a request method (<xref target="methods"/>),		message control data includes a request method (<xref target="methods"/>),
	request target (<xref target="target.resource"/>), and protocol version		request target (<xref target="target.resource"/>), and protocol version
	(<xref target="protocol.version"/>). Response message control data includes		(<xref target="protocol.version"/>). Response message control data includes
	a status code (<xref target="status.codes"/>), optional reason phrase, and		a status code (<xref target="status.codes"/>), optional reason phrase, and
	protocol version.		protocol version.
	</t>		</t>
	<t>		<t>
	In HTTP/1.1 <xref target="RFC9112"/> and earlier, control data is sent		In HTTP/1.1 <xref target="HTTP11"/> and earlier, control data is sent
	as the first line of a message. In HTTP/2 <xref target="RFC7540"/> and		as the first line of a message. In HTTP/2 <xref target="HTTP2"/> and
	HTTP/3 <xref target="RFC9113"/>, control data is sent as pseudo-header		HTTP/3 <xref target="HTTP3"/>, control data is sent as pseudo-header
	fields with a reserved name prefix (e.g., ":authority").		fields with a reserved name prefix (e.g., ":authority").
	</t>		</t>
	<t>		<t>
	Every HTTP message has a protocol version. Depending on the version in use,		Every HTTP message has a protocol version. Depending on the version in use,
	it might be identified within the message explicitly or inferred by the		it might be identified within the message explicitly or inferred by the
	connection over which the message is received. Recipients use that version		connection over which the message is received. Recipients use that version
	information to determine limitations or potential for later communication		information to determine limitations or potential for later communication
	with that sender.		with that sender.
	</t>		</t>
	<t>		<t>
	skipping to change at line 2397 ¶		skipping to change at line 2397 ¶
	<section anchor="content" title="Content">		<section anchor="content" title="Content">
	<iref item="content"/>		<iref item="content"/>
	<t>		<t>
	HTTP messages often transfer a complete or partial representation as the		HTTP messages often transfer a complete or partial representation as the
	message <em>content</em>: a stream of octets sent after the header		message <em>content</em>: a stream of octets sent after the header
	section, as delineated by the message framing.		section, as delineated by the message framing.
	</t>		</t>
	<t>		<t>
	This abstract definition of content reflects the data after it has been		This abstract definition of content reflects the data after it has been
	extracted from the message framing. For example, an HTTP/1.1 message body		extracted from the message framing. For example, an HTTP/1.1 message body
	(<xref target="RFC9112" section="6"/>) might consist of a stream of data enco ded		(<xref target="HTTP11" section="6"/>) might consist of a stream of data encod ed
	with the chunked transfer coding -- a sequence of data chunks, one		with the chunked transfer coding -- a sequence of data chunks, one
	zero-length chunk, and a trailer section -- whereas		zero-length chunk, and a trailer section -- whereas
	the content of that same message		the content of that same message
	includes only the data stream after the transfer coding has been decoded;		includes only the data stream after the transfer coding has been decoded;
	it does not include the chunk lengths, chunked framing syntax, nor the		it does not include the chunk lengths, chunked framing syntax, nor the
	trailer fields (<xref target="trailer.fields"/>).		trailer fields (<xref target="trailer.fields"/>).
	</t>		</t>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> Some field names have a "Content-" pref ix. This is an informal		<strong>Note:</strong> Some field names have a "Content-" pref ix. This is an informal
	skipping to change at line 2551 ¶		skipping to change at line 2551 ¶
	the time the header section was complete. The presence or absence of		the time the header section was complete. The presence or absence of
	certain header fields might impact choices made for the routing or		certain header fields might impact choices made for the routing or
	processing of the message as a whole before the trailers are received;		processing of the message as a whole before the trailers are received;
	those choices cannot be unmade by the later discovery of trailer fields.		those choices cannot be unmade by the later discovery of trailer fields.
	</t>		</t>
	<section anchor="trailers.limitations" title="Limitations on Use of Trailers">		<section anchor="trailers.limitations" title="Limitations on Use of Trailers">
	<t>		<t>
	A trailer section is only possible when supported by the version		A trailer section is only possible when supported by the version
	of HTTP in use and enabled by an explicit framing mechanism.		of HTTP in use and enabled by an explicit framing mechanism.
	For example, the chunked coding in HTTP/1.1 allows a trailer section to be		For example, the chunked coding in HTTP/1.1 allows a trailer section to be
	sent after the content (<xref target="RFC9112" section="7.1.2"/>).		sent after the content (<xref target="HTTP11" section="7.1.2"/>).
	</t>		</t>
	<t>		<t>
	Many fields cannot be processed outside the header section because		Many fields cannot be processed outside the header section because
	their evaluation is necessary prior to receiving the content, such as		their evaluation is necessary prior to receiving the content, such as
	those that describe message framing, routing, authentication,		those that describe message framing, routing, authentication,
	request modifiers, response controls, or content format.		request modifiers, response controls, or content format.
	A sender <bcp14>MUST NOT</bcp14> generate a trailer field unless the sender k nows the		A sender <bcp14>MUST NOT</bcp14> generate a trailer field unless the sender k nows the
	corresponding header field name's definition permits the field to be sent		corresponding header field name's definition permits the field to be sent
	in trailers.		in trailers.
	</t>		</t>
	skipping to change at line 2732 ¶		skipping to change at line 2732 ¶
	Although HTTP is used in a wide variety of applications, most clients rely		Although HTTP is used in a wide variety of applications, most clients rely
	on the same resource identification mechanism and configuration techniques		on the same resource identification mechanism and configuration techniques
	as general-purpose Web browsers. Even when communication options are		as general-purpose Web browsers. Even when communication options are
	hard-coded in a client's configuration, we can think of their combined		hard-coded in a client's configuration, we can think of their combined
	effect as a URI reference (<xref target="uri.references"/>).		effect as a URI reference (<xref target="uri.references"/>).
	</t>		</t>
	<t>		<t>
	A URI reference is resolved to its absolute form in order to obtain the		A URI reference is resolved to its absolute form in order to obtain the
	<em>target URI</em>. The target URI excludes the reference's		<em>target URI</em>. The target URI excludes the reference's
	fragment component, if any, since fragment identifiers are reserved for		fragment component, if any, since fragment identifiers are reserved for
	client-side processing (<xref target="RFC3986" sectionFormat="comma" section= "3.5"/>).		client-side processing (<xref target="URI" sectionFormat="comma" section="3.5 "/>).
	</t>		</t>
	<t>		<t>
	To perform an action on a <em>target resource</em>, the client sends		To perform an action on a <em>target resource</em>, the client sends
	a request message containing enough components of its parsed target URI to		a request message containing enough components of its parsed target URI to
	enable recipients to identify that same resource. For historical reasons,		enable recipients to identify that same resource. For historical reasons,
	the parsed target URI components, collectively referred to as the		the parsed target URI components, collectively referred to as the
	<em>request target</em>, are sent within the message control data		<em>request target</em>, are sent within the message control data
	and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>).		and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>).
	</t>		</t>
	<t>		<t>
	skipping to change at line 2765 ¶		skipping to change at line 2765 ¶
	</ul>		</ul>
	<t>		<t>
	See the respective method definitions for details. These forms <bcp14>MUST NO T</bcp14>		See the respective method definitions for details. These forms <bcp14>MUST NO T</bcp14>
	be used with other methods.		be used with other methods.
	</t>		</t>
	<t>		<t>
	Upon receipt of a client's request, a server reconstructs the target URI		Upon receipt of a client's request, a server reconstructs the target URI
	from the received components in accordance with their local configuration		from the received components in accordance with their local configuration
	and incoming connection context. This reconstruction is specific to each		and incoming connection context. This reconstruction is specific to each
	major protocol version. For example,		major protocol version. For example,
	<xref target="RFC9112" section="3.3"/> defines how a server		<xref target="HTTP11" section="3.3"/> defines how a server
	determines the target URI of an HTTP/1.1 request.		determines the target URI of an HTTP/1.1 request.
	</t>		</t>
	<aside anchor="effective.request.uri">		<aside anchor="effective.request.uri">
	<t>		<t>
	<iref primary="true" item="effective request URI"/>		<iref primary="true" item="effective request URI"/>
	<strong>Note:</strong> Previous specifications defined the rec omposed target URI as a		<strong>Note:</strong> Previous specifications defined the rec omposed target URI as a
	distinct concept, the <em>effective request URI</em>.		distinct concept, the <em>effective request URI</em>.
	</t>		</t>
	</aside>		</aside>
	</section>		</section>
	skipping to change at line 2787 ¶		skipping to change at line 2787 ¶
	<iref primary="true" item="Fields" subitem="Host"/>		<iref primary="true" item="Fields" subitem="Host"/>
	<iref primary="true" item="Header Fields" subitem="Host"/>		<iref primary="true" item="Header Fields" subitem="Host"/>
	<iref primary="true" item="Host header field"/>		<iref primary="true" item="Host header field"/>
	<t>		<t>
	The "Host" header field in a request provides the host and port		The "Host" header field in a request provides the host and port
	information from the target URI, enabling the origin		information from the target URI, enabling the origin
	server to distinguish among resources while servicing requests		server to distinguish among resources while servicing requests
	for multiple host names.		for multiple host names.
	</t>		</t>
	<t>		<t>
	In HTTP/2 <xref target="RFC7540"/> and HTTP/3 <xref target="RFC9113"/>, the		In HTTP/2 <xref target="HTTP2"/> and HTTP/3 <xref target="HTTP3"/>, the
	Host header field is, in some cases, supplanted by the ":authority"		Host header field is, in some cases, supplanted by the ":authority"
	pseudo-header field of a request's control data.		pseudo-header field of a request's control data.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Host"/>		<iref primary="true" item="Grammar" subitem="Host"/>
	<sourcecode type="abnf7230"><![CDATA[ Host = uri-host [ ":" port ] ; Section 4		<sourcecode type="abnf7230"><![CDATA[ Host = uri-host [ ":" port ] ; Section 4
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The target URI's authority information is critical for handling a		The target URI's authority information is critical for handling a
	request. A user agent <bcp14>MUST</bcp14> generate a Host header field in a r equest		request. A user agent <bcp14>MUST</bcp14> generate a Host header field in a r equest
	unless it sends that information as an ":authority" pseudo-header field.		unless it sends that information as an ":authority" pseudo-header field.
	skipping to change at line 2827 ¶		skipping to change at line 2827 ¶
	</t>		</t>
	</section>		</section>
	<section anchor="routing.inbound" title="Routing Inbound Requests">		<section anchor="routing.inbound" title="Routing Inbound Requests">
	<t>		<t>
	Once the target URI and its origin are determined, a client decides whether		Once the target URI and its origin are determined, a client decides whether
	a network request is necessary to accomplish the desired semantics and,		a network request is necessary to accomplish the desired semantics and,
	if so, where that request is to be directed.		if so, where that request is to be directed.
	</t>		</t>
	<section anchor="routing.cache" title="To a Cache">		<section anchor="routing.cache" title="To a Cache">
	<t>		<t>
	If the client has a cache <xref target="RFC9111"/> and the request can be		If the client has a cache <xref target="CACHING"/> and the request can be
	satisfied by it, then the request is		satisfied by it, then the request is
	usually directed there first.		usually directed there first.
	</t>		</t>
	</section>		</section>
	<section anchor="routing.proxy" title="To a Proxy">		<section anchor="routing.proxy" title="To a Proxy">
	<t>		<t>
	If the request is not satisfied by a cache, then a typical client will		If the request is not satisfied by a cache, then a typical client will
	check its configuration to determine whether a proxy is to be used to		check its configuration to determine whether a proxy is to be used to
	satisfy the request. Proxy configuration is implementation-dependent,		satisfy the request. Proxy configuration is implementation-dependent,
	but is often based on URI prefix matching, selective authority matching,		but is often based on URI prefix matching, selective authority matching,
	skipping to change at line 2924 ¶		skipping to change at line 2924 ¶
	responses) can be sent at any time after a request is received, even if the		responses) can be sent at any time after a request is received, even if the
	request is not yet complete. A response can complete before its		request is not yet complete. A response can complete before its
	corresponding request is complete (<xref target="message.framing"/>). Likewis e, clients are not expected		corresponding request is complete (<xref target="message.framing"/>). Likewis e, clients are not expected
	to wait any specific amount of time for a response. Clients		to wait any specific amount of time for a response. Clients
	(including intermediaries) might abandon a request if the response is not		(including intermediaries) might abandon a request if the response is not
	received within a reasonable period of time.		received within a reasonable period of time.
	</t>		</t>
	<t>		<t>
	A client that receives a response while it is still sending the associated		A client that receives a response while it is still sending the associated
	request <bcp14>SHOULD</bcp14> continue sending that request unless it receive s		request <bcp14>SHOULD</bcp14> continue sending that request unless it receive s
	an explicit indication to the contrary (see, e.g., <xref target="RFC9112" sec tion="9.5"/> and <xref target="RFC7540" section="6.4"/>).		an explicit indication to the contrary (see, e.g., <xref target="HTTP11" sect ion="9.5"/> and <xref target="HTTP2" section="6.4"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="message.forwarding" title="Message Forwarding">		<section anchor="message.forwarding" title="Message Forwarding">
	<t>		<t>
	As described in <xref target="intermediaries"/>, intermediaries can serve		As described in <xref target="intermediaries"/>, intermediaries can serve
	a variety of roles in the processing of HTTP requests and responses.		a variety of roles in the processing of HTTP requests and responses.
	Some intermediaries are used to improve performance or availability.		Some intermediaries are used to improve performance or availability.
	Others are used for access control or to filter content.		Others are used for access control or to filter content.
	Since an HTTP stream has characteristics similar to a pipe-and-filter		Since an HTTP stream has characteristics similar to a pipe-and-filter
	architecture, there are no inherent limits to the extent an intermediary		architecture, there are no inherent limits to the extent an intermediary
	skipping to change at line 3000 ¶		skipping to change at line 3000 ¶
	message to be self-descriptive and allowing future connection-specific		message to be self-descriptive and allowing future connection-specific
	extensions to be deployed without fear that they will be blindly		extensions to be deployed without fear that they will be blindly
	forwarded by older intermediaries.		forwarded by older intermediaries.
	</t>		</t>
	<t>		<t>
	Furthermore, intermediaries <bcp14>SHOULD</bcp14> remove or replace field(s) whose		Furthermore, intermediaries <bcp14>SHOULD</bcp14> remove or replace field(s) whose
	semantics are known to require removal before forwarding, whether or not they appear as a connection		semantics are known to require removal before forwarding, whether or not they appear as a connection
	option, after applying those fields' semantics. This includes but is not limi ted to:		option, after applying those fields' semantics. This includes but is not limi ted to:
	</t>		</t>
	<ul>		<ul>
	<li>Proxy-Connection (<xref target="RFC9112" section="C.2.2"/> )</li>		<li>Proxy-Connection (<xref target="HTTP11" section="C.2.2"/>) </li>
	<li>Keep-Alive (<xref target="RFC2068" section="19.7.1"/>)</li >		<li>Keep-Alive (<xref target="RFC2068" section="19.7.1"/>)</li >
	<li>TE (<xref target="field.te"/>)</li>		<li>TE (<xref target="field.te"/>)</li>
	<li>Transfer-Encoding (<xref target="RFC9112" section="6.1"/>) </li>		<li>Transfer-Encoding (<xref target="HTTP11" section="6.1"/>)< /li>
	<li>Upgrade (<xref target="field.upgrade"/>)</li>		<li>Upgrade (<xref target="field.upgrade"/>)</li>
	</ul>		</ul>
	<t>		<t>
	The Connection header field's value has the following grammar:		The Connection header field's value has the following grammar:
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Connection"/>		<iref primary="true" item="Grammar" subitem="Connection"/>
	<iref primary="true" item="Grammar" subitem="connection-option"/>		<iref primary="true" item="Grammar" subitem="connection-option"/>
	<sourcecode type="abnf7230"><![CDATA[ Connection = #conne ction-option		<sourcecode type="abnf7230"><![CDATA[ Connection = #conne ction-option
	connection-option = token		connection-option = token
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	Connection options are case-insensitive.		Connection options are case-insensitive.
	</t>		</t>
	<t>		<t>
	A sender <bcp14>MUST NOT</bcp14> send a connection option corresponding to a		A sender <bcp14>MUST NOT</bcp14> send a connection option corresponding to a
	field that is intended for all recipients of the content.		field that is intended for all recipients of the content.
	For example, Cache-Control is never appropriate as a		For example, Cache-Control is never appropriate as a
	connection option (<xref target="RFC9111" section="5.2"/>).		connection option (<xref target="CACHING" section="5.2"/>).
	</t>		</t>
	<t>		<t>
	Connection options do not always correspond to a field		Connection options do not always correspond to a field
	present in the message, since a connection-specific field		present in the message, since a connection-specific field
	might not be needed if there are no parameters associated with a		might not be needed if there are no parameters associated with a
	connection option. In contrast, a connection-specific field		connection option. In contrast, a connection-specific field
	received without a corresponding connection option usually indicates		received without a corresponding connection option usually indicates
	that the field has been improperly forwarded by an intermediary and		that the field has been improperly forwarded by an intermediary and
	ought to be ignored by the recipient.		ought to be ignored by the recipient.
	</t>		</t>
	skipping to change at line 3228 ¶		skipping to change at line 3228 ¶
	If a proxy receives a target URI with a host name that is not a		If a proxy receives a target URI with a host name that is not a
	fully qualified domain name, it <bcp14>MAY</bcp14> add its own domain to the host name		fully qualified domain name, it <bcp14>MAY</bcp14> add its own domain to the host name
	it received when forwarding the request. A proxy <bcp14>MUST NOT</bcp14> cha nge the		it received when forwarding the request. A proxy <bcp14>MUST NOT</bcp14> cha nge the
	host name if the target URI contains a fully qualified domain name.		host name if the target URI contains a fully qualified domain name.
	</t>		</t>
	<t>		<t>
	A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "query" parts of the		A proxy <bcp14>MUST NOT</bcp14> modify the "absolute-path" and "query" parts of the
	received target URI when forwarding it to the next inbound server except		received target URI when forwarding it to the next inbound server except
	as required by that forwarding protocol. For example, a proxy forwarding		as required by that forwarding protocol. For example, a proxy forwarding
	a request to an origin server via HTTP/1.1 will replace an empty path with		a request to an origin server via HTTP/1.1 will replace an empty path with
	"/" (<xref target="RFC9112" section="3.2.1"/>) or "*" (<xref target="RFC9112" section="3.2.4"/>),		"/" (<xref target="HTTP11" section="3.2.1"/>) or "*" (<xref target="HTTP11" s ection="3.2.4"/>),
	depending on the request method.		depending on the request method.
	</t>		</t>
	<t>		<t>
	A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target="content" />) of a message that		A proxy <bcp14>MUST NOT</bcp14> transform the content (<xref target="content" />) of a message that
	contains a "no-transform" Cache-Control response directive (<xref target="RFC 9111" section="5.2"/>).		contains a "no-transform" Cache-Control response directive (<xref target="CAC HING" section="5.2"/>).
	Note that this does not include changes to the message body that do not affec t		Note that this does not include changes to the message body that do not affec t
	the content, such as transfer codings (<xref target="RFC9112" section="7"/>).		the content, such as transfer codings (<xref target="HTTP11" section="7"/>).
	</t>		</t>
	<t>		<t>
	A proxy <bcp14>MAY</bcp14> transform the content of a message		A proxy <bcp14>MAY</bcp14> transform the content of a message
	that does not contain a no-transform Cache-Control directive.		that does not contain a no-transform Cache-Control directive.
	A proxy that transforms the content of a <xref target="status.200" format="no ne">200 (OK)</xref> response		A proxy that transforms the content of a <xref target="status.200" format="no ne">200 (OK)</xref> response
	can inform downstream recipients that a transformation has been		can inform downstream recipients that a transformation has been
	applied by changing the response status code to		applied by changing the response status code to
	<xref target="status.203" format="none">203 (Non-Authoritative Information)</ xref> (<xref target="status.203"/>).		<xref target="status.203" format="none">203 (Non-Authoritative Information)</ xref> (<xref target="status.203"/>).
	</t>		</t>
	<t>		<t>
	skipping to change at line 3589 ¶		skipping to change at line 3589 ¶
	that applied the encodings <bcp14>MUST</bcp14> generate a Content-Encoding he ader field		that applied the encodings <bcp14>MUST</bcp14> generate a Content-Encoding he ader field
	that lists the content codings in the order in which they were applied.		that lists the content codings in the order in which they were applied.
	Note that the coding named "identity" is reserved for its special role		Note that the coding named "identity" is reserved for its special role
	in <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> and thus <bcp14>SHOULD NOT</bcp14> be included.		in <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> and thus <bcp14>SHOULD NOT</bcp14> be included.
	</t>		</t>
	<t>		<t>
	Additional information about the encoding parameters can be provided		Additional information about the encoding parameters can be provided
	by other header fields not defined by this specification.		by other header fields not defined by this specification.
	</t>		</t>
	<t>		<t>
	Unlike Transfer-Encoding (<xref target="RFC9112" section="6.1"/>), the coding s listed		Unlike Transfer-Encoding (<xref target="HTTP11" section="6.1"/>), the codings listed
	in Content-Encoding are a characteristic of the representation; the		in Content-Encoding are a characteristic of the representation; the
	representation is defined in terms of the coded form, and all other		representation is defined in terms of the coded form, and all other
	metadata about the representation is about the coded form unless otherwise		metadata about the representation is about the coded form unless otherwise
	noted in the metadata definition. Typically, the representation is only		noted in the metadata definition. Typically, the representation is only
	decoded just prior to rendering or analogous usage.		decoded just prior to rendering or analogous usage.
	</t>		</t>
	<t>		<t>
	If the media type includes an inherent encoding, such as a data format		If the media type includes an inherent encoding, such as a data format
	that is always compressed, then that encoding would not be restated in		that is always compressed, then that encoding would not be restated in
	Content-Encoding even if it happens to be the same algorithm as one		Content-Encoding even if it happens to be the same algorithm as one
	skipping to change at line 3770 ¶		skipping to change at line 3770 ¶
	</section>		</section>
	<section anchor="field.content-length" title="Content-Length">		<section anchor="field.content-length" title="Content-Length">
	<iref primary="true" item="Fields" subitem="Content-Length"/>		<iref primary="true" item="Fields" subitem="Content-Length"/>
	<iref primary="true" item="Header Fields" subitem="Content-Length"/>		<iref primary="true" item="Header Fields" subitem="Content-Length"/>
	<iref primary="true" item="Content-Length header field"/>		<iref primary="true" item="Content-Length header field"/>
	<t>		<t>
	The "Content-Length" header field indicates the associated representation's		The "Content-Length" header field indicates the associated representation's
	data length as a decimal non-negative integer number of octets.		data length as a decimal non-negative integer number of octets.
	When transferring a representation as content, Content-Length refers		When transferring a representation as content, Content-Length refers
	specifically to the amount of data enclosed so that it can be used to		specifically to the amount of data enclosed so that it can be used to
	delimit framing (e.g., <xref target="RFC9112" section="6.2"/>).		delimit framing (e.g., <xref target="HTTP11" section="6.2"/>).
	In other cases, Content-Length indicates the selected representation's		In other cases, Content-Length indicates the selected representation's
	current length, which can be used by recipients to estimate transfer time		current length, which can be used by recipients to estimate transfer time
	or to compare to previously stored representations.		or to compare to previously stored representations.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Content-Length"/>		<iref primary="true" item="Grammar" subitem="Content-Length"/>
	<sourcecode type="abnf7230"><![CDATA[ Content-Length = 1*DIGIT		<sourcecode type="abnf7230"><![CDATA[ Content-Length = 1*DIGIT
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	An example is		An example is
	</t>		</t>
	skipping to change at line 3873 ¶		skipping to change at line 3873 ¶
	of this message's generation, then a <xref target="status.200" format="none"> 200 (OK)</xref> response would		of this message's generation, then a <xref target="status.200" format="none"> 200 (OK)</xref> response would
	contain the same representation that is enclosed as content in this message.		contain the same representation that is enclosed as content in this message.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Content-Location"/>		<iref primary="true" item="Grammar" subitem="Content-Location"/>
	<sourcecode type="abnf7230"><![CDATA[ Content-Location = absolute-U RI / partial-URI		<sourcecode type="abnf7230"><![CDATA[ Content-Location = absolute-U RI / partial-URI
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a		The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a
	<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),		<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),
	the referenced URI is relative to the target URI		the referenced URI is relative to the target URI
	(<xref target="RFC3986" sectionFormat="comma" section="5"/>).		(<xref target="URI" sectionFormat="comma" section="5"/>).
	</t>		</t>
	<t>		<t>
	The Content-Location value is not a replacement for the target URI		The Content-Location value is not a replacement for the target URI
	(<xref target="target.resource"/>). It is representation metadata.		(<xref target="target.resource"/>). It is representation metadata.
	It has the same syntax and semantics as the header field of the same name		It has the same syntax and semantics as the header field of the same name
	defined for MIME body parts in <xref target="RFC2557" section="4"/>.		defined for MIME body parts in <xref target="RFC2557" section="4"/>.
	However, its appearance in an HTTP message has some special implications		However, its appearance in an HTTP message has some special implications
	for HTTP recipients.		for HTTP recipients.
	</t>		</t>
	<t>		<t>
	skipping to change at line 3991 ¶		skipping to change at line 3991 ¶
	representation, so that the entity-tag can be used as a validator in		representation, so that the entity-tag can be used as a validator in
	later conditional requests to prevent the "lost update" problem.		later conditional requests to prevent the "lost update" problem.
	</t>		</t>
	<t>		<t>
	This specification defines two forms of metadata that are commonly used		This specification defines two forms of metadata that are commonly used
	to observe resource state and test for preconditions: modification dates		to observe resource state and test for preconditions: modification dates
	(<xref target="field.last-modified"/>) and opaque entity tags		(<xref target="field.last-modified"/>) and opaque entity tags
	(<xref target="field.etag"/>).		(<xref target="field.etag"/>).
	Additional metadata that reflects resource state		Additional metadata that reflects resource state
	has been defined by various extensions of HTTP, such as Web Distributed		has been defined by various extensions of HTTP, such as Web Distributed
	Authoring and Versioning <xref target="RFC4918"/>, that are beyond the		Authoring and Versioning <xref target="WEBDAV"/>, that are beyond the
	scope of this specification.		scope of this specification.
	</t>		</t>
	<section anchor="weak.and.strong.validators" title="Weak versus Stro ng">		<section anchor="weak.and.strong.validators" title="Weak versus Stro ng">
	<iref primary="true" item="validator" subitem="weak"/>		<iref primary="true" item="validator" subitem="weak"/>
	<iref primary="true" item="validator" subitem="strong"/>		<iref primary="true" item="validator" subitem="strong"/>
	<t>		<t>
	Validators come in two flavors: strong or weak. Weak validators are easy		Validators come in two flavors: strong or weak. Weak validators are easy
	to generate but are far less useful for comparisons. Strong validators		to generate but are far less useful for comparisons. Strong validators
	are ideal for comparisons but can be very difficult (and occasionally		are ideal for comparisons but can be very difficult (and occasionally
	impossible) to generate efficiently. Rather than impose that all forms		impossible) to generate efficiently. Rather than impose that all forms
	skipping to change at line 4115 ¶		skipping to change at line 4115 ¶
	<t>		<t>
	An example of its use is		An example of its use is
	</t>		</t>
	<sourcecode type="http-message"><![CDATA[Last-Modified: Tue, 15 N ov 1994 12:45:26 GMT		<sourcecode type="http-message"><![CDATA[Last-Modified: Tue, 15 N ov 1994 12:45:26 GMT
	]]></sourcecode>		]]></sourcecode>
	<section anchor="lastmod.generation" title="Generation">		<section anchor="lastmod.generation" title="Generation">
	<t>		<t>
	An origin server <bcp14>SHOULD</bcp14> send Last-Modified for any selected		An origin server <bcp14>SHOULD</bcp14> send Last-Modified for any selected
	representation for which a last modification date can be reasonably		representation for which a last modification date can be reasonably
	and consistently determined, since its use in conditional requests		and consistently determined, since its use in conditional requests
	and evaluating cache freshness <xref target="RFC9111"/> can		and evaluating cache freshness <xref target="CACHING"/> can
	substantially reduce unnecessary transfers and significantly		substantially reduce unnecessary transfers and significantly
	improve service availability and scalability.		improve service availability and scalability.
	</t>		</t>
	<t>		<t>
	A representation is typically the sum of many parts behind the		A representation is typically the sum of many parts behind the
	resource interface. The last-modified time would usually be		resource interface. The last-modified time would usually be
	the most recent time that any of those parts were changed.		the most recent time that any of those parts were changed.
	How that value is determined for any given resource is an		How that value is determined for any given resource is an
	implementation detail beyond the scope of this specification.		implementation detail beyond the scope of this specification.
	</t>		</t>
	skipping to change at line 4286 ¶		skipping to change at line 4286 ¶
	combined with a variance identifier for content negotiation, to		combined with a variance identifier for content negotiation, to
	accurately differentiate between representations.		accurately differentiate between representations.
	Other implementations might use a collision-resistant hash of		Other implementations might use a collision-resistant hash of
	representation content, a combination of various file attributes, or		representation content, a combination of various file attributes, or
	a modification timestamp that has sub-second resolution.		a modification timestamp that has sub-second resolution.
	</t>		</t>
	<t>		<t>
	An origin server <bcp14>SHOULD</bcp14> send an ETag for any selected represen tation		An origin server <bcp14>SHOULD</bcp14> send an ETag for any selected represen tation
	for which detection of changes can be reasonably and consistently		for which detection of changes can be reasonably and consistently
	determined, since the entity-tag's use in conditional requests and		determined, since the entity-tag's use in conditional requests and
	evaluating cache freshness <xref target="RFC9111"/> can		evaluating cache freshness <xref target="CACHING"/> can
	substantially reduce unnecessary transfers and significantly		substantially reduce unnecessary transfers and significantly
	improve service availability, scalability, and reliability.		improve service availability, scalability, and reliability.
	</t>		</t>
	</section>		</section>
	<section anchor="entity.tag.comparison" title="Comparison">		<section anchor="entity.tag.comparison" title="Comparison">
	<t>		<t>
	There are two entity-tag comparison functions, depending on whether or not		There are two entity-tag comparison functions, depending on whether or not
	the comparison context allows the use of weak validators:		the comparison context allows the use of weak validators:
	</t>		</t>
	<dl>		<dl>
	skipping to change at line 4410 ¶		skipping to change at line 4410 ¶
	Content-Type: text/plain		Content-Type: text/plain
	Content-Encoding: gzip		Content-Encoding: gzip
	...binary data...]]></sourcecode>		...binary data...]]></sourcecode>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> Content codings are a property of the representation data,		<strong>Note:</strong> Content codings are a property of the representation data,
	so a strong entity-tag for a content-encoded representation has to be		so a strong entity-tag for a content-encoded representation has to be
	distinct from the entity tag of an unencoded representation to prevent		distinct from the entity tag of an unencoded representation to prevent
	potential conflicts during cache updates and range requests. In contrast,		potential conflicts during cache updates and range requests. In contrast,
	transfer codings (<xref target="RFC9112" section="7"/>) apply only during me ssage transfer		transfer codings (<xref target="HTTP11" section="7"/>) apply only during mes sage transfer
	and do not result in distinct entity-tags.		and do not result in distinct entity-tags.
	</t>		</t>
	</aside>		</aside>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="methods" title="Methods">		<section anchor="methods" title="Methods">
	<section anchor="method.overview" title="Overview">		<section anchor="method.overview" title="Overview">
	<t>		<t>
	skipping to change at line 4665 ¶		skipping to change at line 4665 ¶
	<t>		<t>
	A proxy <bcp14>MUST NOT</bcp14> automatically retry non-idempotent requests.		A proxy <bcp14>MUST NOT</bcp14> automatically retry non-idempotent requests.
	A client <bcp14>SHOULD NOT</bcp14> automatically retry a failed automatic ret ry.		A client <bcp14>SHOULD NOT</bcp14> automatically retry a failed automatic ret ry.
	</t>		</t>
	</section>		</section>
	<section anchor="cacheable.methods" title="Methods and Caching">		<section anchor="cacheable.methods" title="Methods and Caching">
	<t>		<t>
	For a cache to store and use a response, the associated method needs to		For a cache to store and use a response, the associated method needs to
	explicitly allow caching and to detail under what conditions a response can		explicitly allow caching and to detail under what conditions a response can
	be used to satisfy subsequent requests; a method definition that does not		be used to satisfy subsequent requests; a method definition that does not
	do so cannot be cached. For additional requirements see <xref target="RFC9111 "/>.		do so cannot be cached. For additional requirements see <xref target="CACHING "/>.
	</t>		</t>
	<t>		<t>
	This specification defines caching semantics for GET, HEAD, and POST,		This specification defines caching semantics for GET, HEAD, and POST,
	although the overwhelming majority of cache implementations only support		although the overwhelming majority of cache implementations only support
	GET and HEAD.		GET and HEAD.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="method.definitions" title="Method Definitions">		<section anchor="method.definitions" title="Method Definitions">
	<section anchor="GET" title="GET">		<section anchor="GET" title="GET">
	<iref primary="true" item="GET method"/>		<iref primary="true" item="GET method"/>
	<iref primary="true" item="Method" subitem="GET"/>		<iref primary="true" item="Method" subitem="GET"/>
	<t>		<t>
	The GET method requests transfer of a current		The GET method requests transfer of a current
	<xref target="selected.representation" format="none">selected representation< /xref> for the		<xref target="selected.representation" format="none">selected representation< /xref> for the
	<xref target="target.resource" format="none">target resource</xref>.		<xref target="target.resource" format="none">target resource</xref>.
	A successful response reflects the quality of "sameness" identified by		A successful response reflects the quality of "sameness" identified by
	the target URI (<xref target="RFC3986" section="1.2.2"/>). Hence,		the target URI (<xref target="URI" section="1.2.2"/>). Hence,
	retrieving identifiable information via HTTP is usually performed by		retrieving identifiable information via HTTP is usually performed by
	making a GET request on an identifier associated with the potential for		making a GET request on an identifier associated with the potential for
	providing that information in a <xref target="status.200" format="none">200 ( OK)</xref> response.		providing that information in a <xref target="status.200" format="none">200 ( OK)</xref> response.
	</t>		</t>
	<t>		<t>
	GET is the primary mechanism of information retrieval and the focus of		GET is the primary mechanism of information retrieval and the focus of
	almost all performance optimizations. Applications that produce a URI for		almost all performance optimizations. Applications that produce a URI for
	each important resource can benefit from those optimizations while enabling		each important resource can benefit from those optimizations while enabling
	their reuse by other applications, creating a network effect that promotes		their reuse by other applications, creating a network effect that promotes
	further expansion of the Web.		further expansion of the Web.
	skipping to change at line 4725 ¶		skipping to change at line 4725 ¶
	A client can alter the semantics of GET to be a "range request", requesting		A client can alter the semantics of GET to be a "range request", requesting
	transfer of only some part(s) of the selected representation, by sending a		transfer of only some part(s) of the selected representation, by sending a
	<xref target="field.range" format="none">Range</xref> header field in the req uest (<xref target="field.range"/>).		<xref target="field.range" format="none">Range</xref> header field in the req uest (<xref target="field.range"/>).
	</t>		</t>
	<t>		<t>
	Although request message framing is independent of the method used,		Although request message framing is independent of the method used,
	content received in a GET request has no generally defined semantics,		content received in a GET request has no generally defined semantics,
	cannot alter the meaning or target of the request, and might lead some		cannot alter the meaning or target of the request, and might lead some
	implementations to reject the request and close the connection because of		implementations to reject the request and close the connection because of
	its potential as a request smuggling attack		its potential as a request smuggling attack
	(<xref target="RFC9112" section="11.2"/>).		(<xref target="HTTP11" section="11.2"/>).
	A client <bcp14>SHOULD NOT</bcp14> generate content in a GET request unless i t is		A client <bcp14>SHOULD NOT</bcp14> generate content in a GET request unless i t is
	made directly to an origin server that has previously indicated,		made directly to an origin server that has previously indicated,
	in or out of band, that such a request has a purpose and will be adequately		in or out of band, that such a request has a purpose and will be adequately
	supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to		supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to
	receive content, since participants in HTTP communication are often		receive content, since participants in HTTP communication are often
	unaware of intermediaries along the request chain.		unaware of intermediaries along the request chain.
	</t>		</t>
	<t>		<t>
	The response to a GET request is cacheable; a cache <bcp14>MAY</bcp14> use it to satisfy		The response to a GET request is cacheable; a cache <bcp14>MAY</bcp14> use it to satisfy
	subsequent GET and HEAD requests unless otherwise indicated by the		subsequent GET and HEAD requests unless otherwise indicated by the
	Cache-Control header field (<xref target="RFC9111" section="5.2"/>).		Cache-Control header field (<xref target="CACHING" section="5.2"/>).
	</t>		</t>
	<t>		<t>
	When information retrieval is performed with a mechanism that constructs a		When information retrieval is performed with a mechanism that constructs a
	target URI from user-provided information, such as the query fields of a		target URI from user-provided information, such as the query fields of a
	form using GET, potentially sensitive data might be provided that would not		form using GET, potentially sensitive data might be provided that would not
	be appropriate for disclosure within a URI		be appropriate for disclosure within a URI
	(see <xref target="sensitive.information.in.uris"/>). In some cases, the		(see <xref target="sensitive.information.in.uris"/>). In some cases, the
	data can be filtered or transformed such that it would not reveal such		data can be filtered or transformed such that it would not reveal such
	information. In others, particularly when there is no benefit from caching		information. In others, particularly when there is no benefit from caching
	a response, using the POST method (<xref target="POST"/>) instead of GET		a response, using the POST method (<xref target="POST"/>) instead of GET
	skipping to change at line 4781 ¶		skipping to change at line 4781 ¶
	inconsistencies are considered preferable to generating and discarding the		inconsistencies are considered preferable to generating and discarding the
	content for a HEAD request, since HEAD is usually requested for the		content for a HEAD request, since HEAD is usually requested for the
	sake of efficiency.		sake of efficiency.
	</t>		</t>
	<t>		<t>
	Although request message framing is independent of the method used,		Although request message framing is independent of the method used,
	content received in a HEAD request has no generally defined semantics,		content received in a HEAD request has no generally defined semantics,
	cannot alter the meaning or target of the request, and might lead some		cannot alter the meaning or target of the request, and might lead some
	implementations to reject the request and close the connection because of		implementations to reject the request and close the connection because of
	its potential as a request smuggling attack		its potential as a request smuggling attack
	(<xref target="RFC9112" section="11.2"/>).		(<xref target="HTTP11" section="11.2"/>).
	A client <bcp14>SHOULD NOT</bcp14> generate content in a HEAD request unless it is		A client <bcp14>SHOULD NOT</bcp14> generate content in a HEAD request unless it is
	made directly to an origin server that has previously indicated,		made directly to an origin server that has previously indicated,
	in or out of band, that such a request has a purpose and will be adequately		in or out of band, that such a request has a purpose and will be adequately
	supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to		supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to
	receive content, since participants in HTTP communication are often		receive content, since participants in HTTP communication are often
	unaware of intermediaries along the request chain.		unaware of intermediaries along the request chain.
	</t>		</t>
	<t>		<t>
	The response to a HEAD request is cacheable; a cache <bcp14>MAY</bcp14> use i t to		The response to a HEAD request is cacheable; a cache <bcp14>MAY</bcp14> use i t to
	satisfy subsequent HEAD requests unless otherwise indicated by the		satisfy subsequent HEAD requests unless otherwise indicated by the
	Cache-Control header field (<xref target="RFC9111" section="5.2"/>).		Cache-Control header field (<xref target="CACHING" section="5.2"/>).
	A HEAD response might also affect previously cached responses to GET;		A HEAD response might also affect previously cached responses to GET;
	see <xref target="RFC9111" section="4.3.5"/>.		see <xref target="CACHING" section="4.3.5"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="POST" title="POST">		<section anchor="POST" title="POST">
	<iref primary="true" item="POST method"/>		<iref primary="true" item="POST method"/>
	<iref primary="true" item="Method" subitem="POST"/>		<iref primary="true" item="Method" subitem="POST"/>
	<t>		<t>
	The POST method requests that the <xref target="target.resource" format="none ">target resource</xref> process		The POST method requests that the <xref target="target.resource" format="none ">target resource</xref> process
	the representation enclosed in the request according to the resource's own		the representation enclosed in the request according to the resource's own
	specific semantics. For example, POST is used for the following functions		specific semantics. For example, POST is used for the following functions
	(among others):		(among others):
	skipping to change at line 4847 ¶		skipping to change at line 4847 ¶
	[CACHING].		[CACHING].
	Perhaps:		Perhaps:
	A cached POST response can be reused to satisfy a later GET or HEAD		A cached POST response can be reused to satisfy a later GET or HEAD
	request, but not a POST request. Because the POST method is unsafe,		request, but not a POST request. Because the POST method is unsafe,
	the cache writes POST requests through to the origin server; see		the cache writes POST requests through to the origin server; see
	Section 4 of [CACHING].		Section 4 of [CACHING].
	-->		-->
	<t>		<t>
	Responses to POST requests are only cacheable when they include explicit		Responses to POST requests are only cacheable when they include explicit
	freshness information (see <xref target="RFC9111" section="4.2.1"/>) and a		freshness information (see <xref target="CACHING" section="4.2.1"/>) and a
	<xref target="field.content-location" format="none">Content-Location</xref> h eader field that has the same value as		<xref target="field.content-location" format="none">Content-Location</xref> h eader field that has the same value as
	the POST's target URI (<xref target="field.content-location"/>). A cached POS T response can be reused		the POST's target URI (<xref target="field.content-location"/>). A cached POS T response can be reused
	to satisfy a later GET or HEAD request, but not a POST request, since POST		to satisfy a later GET or HEAD request, but not a POST request, since POST
	is required to be written through to the origin server, because it is		is required to be written through to the origin server, because it is
	unsafe; see <xref target="RFC9111" section="4"/>.		unsafe; see <xref target="CACHING" section="4"/>.
	</t>		</t>
	<t>		<t>
	If the result of processing a POST would be equivalent to a representation		If the result of processing a POST would be equivalent to a representation
	of an existing resource, an origin server <bcp14>MAY</bcp14> redirect the use r agent to		of an existing resource, an origin server <bcp14>MAY</bcp14> redirect the use r agent to
	that resource by sending a <xref target="status.303" format="none">303 (See O ther)</xref> response with the		that resource by sending a <xref target="status.303" format="none">303 (See O ther)</xref> response with the
	existing resource's identifier in the <xref target="field.location" format="n one">Location</xref> field.		existing resource's identifier in the <xref target="field.location" format="n one">Location</xref> field.
	This has the benefits of providing the user agent a resource identifier		This has the benefits of providing the user agent a resource identifier
	and transferring the representation via a method more amenable to shared		and transferring the representation via a method more amenable to shared
	caching, though at the cost of an extra request if the user agent does not		caching, though at the cost of an extra request if the user agent does not
	already have the representation cached.		already have the representation cached.
	skipping to change at line 4997 ¶		skipping to change at line 4997 ¶
	</t>		</t>
	<t>		<t>
	Some origin servers support use of the <xref target="field.content-range" for mat="none">Content-Range</xref> header		Some origin servers support use of the <xref target="field.content-range" for mat="none">Content-Range</xref> header
	field (<xref target="field.content-range"/>) as a request modifier to		field (<xref target="field.content-range"/>) as a request modifier to
	perform a partial PUT, as described in <xref target="partial.PUT"/>.		perform a partial PUT, as described in <xref target="partial.PUT"/>.
	</t>		</t>
	<t>		<t>
	Responses to the PUT method are not cacheable. If a successful PUT request		Responses to the PUT method are not cacheable. If a successful PUT request
	passes through a cache that has one or more stored responses for the		passes through a cache that has one or more stored responses for the
	target URI, those stored responses will be invalidated		target URI, those stored responses will be invalidated
	(see <xref target="RFC9111" section="4.4"/>).		(see <xref target="CACHING" section="4.4"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="DELETE" title="DELETE">		<section anchor="DELETE" title="DELETE">
	<iref primary="true" item="DELETE method"/>		<iref primary="true" item="DELETE method"/>
	<iref primary="true" item="Method" subitem="DELETE"/>		<iref primary="true" item="Method" subitem="DELETE"/>
	<t>		<t>
	The DELETE method requests that the origin server remove the association		The DELETE method requests that the origin server remove the association
	between the <xref target="target.resource" format="none">target resource</xre f> and its current functionality.		between the <xref target="target.resource" format="none">target resource</xre f> and its current functionality.
	In effect, this method is similar to the "rm" command in UNIX: it expresses a		In effect, this method is similar to the "rm" command in UNIX: it expresses a
	deletion operation on the URI mapping of the origin server rather than an		deletion operation on the URI mapping of the origin server rather than an
	skipping to change at line 5050 ¶		skipping to change at line 5050 ¶
	enacted and no further information is to be supplied, or</li>		enacted and no further information is to be supplied, or</li>
	<li>a <xref target="status.200" format="none">200 (OK)</xref> status code if the action has been enacted and		<li>a <xref target="status.200" format="none">200 (OK)</xref> status code if the action has been enacted and
	the response message includes a representation describing the status.</li>		the response message includes a representation describing the status.</li>
	</ul>		</ul>
	<t>		<t>
	Although request message framing is independent of the method used,		Although request message framing is independent of the method used,
	content received in a DELETE request has no generally defined semantics,		content received in a DELETE request has no generally defined semantics,
	cannot alter the meaning or target of the request, and might lead some		cannot alter the meaning or target of the request, and might lead some
	implementations to reject the request and close the connection because of		implementations to reject the request and close the connection because of
	its potential as a request smuggling attack		its potential as a request smuggling attack
	(<xref target="RFC9112" section="11.2"/>).		(<xref target="HTTP11" section="11.2"/>).
	A client <bcp14>SHOULD NOT</bcp14> generate content in a DELETE request unles s it is		A client <bcp14>SHOULD NOT</bcp14> generate content in a DELETE request unles s it is
	made directly to an origin server that has previously indicated,		made directly to an origin server that has previously indicated,
	in or out of band, that such a request has a purpose and will be adequately		in or out of band, that such a request has a purpose and will be adequately
	supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to		supported. An origin server <bcp14>SHOULD NOT</bcp14> rely on private agreeme nts to
	receive content, since participants in HTTP communication are often		receive content, since participants in HTTP communication are often
	unaware of intermediaries along the request chain.		unaware of intermediaries along the request chain.
	</t>		</t>
	<t>		<t>
	Responses to the DELETE method are not cacheable. If a successful DELETE		Responses to the DELETE method are not cacheable. If a successful DELETE
	request passes through a cache that has one or more stored responses for		request passes through a cache that has one or more stored responses for
	the target URI, those stored responses will be invalidated (see		the target URI, those stored responses will be invalidated (see
	<xref target="RFC9111" section="4.4"/>).		<xref target="CACHING" section="4.4"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="CONNECT" title="CONNECT">		<section anchor="CONNECT" title="CONNECT">
	<iref primary="true" item="CONNECT method"/>		<iref primary="true" item="CONNECT method"/>
	<iref primary="true" item="Method" subitem="CONNECT"/>		<iref primary="true" item="Method" subitem="CONNECT"/>
	<t>		<t>
	The CONNECT method requests that the recipient establish a tunnel to the		The CONNECT method requests that the recipient establish a tunnel to the
	destination origin server identified by the request target and, if		destination origin server identified by the request target and, if
	successful, thereafter restrict its behavior to blind forwarding of		successful, thereafter restrict its behavior to blind forwarding of
	data, in both directions, until the tunnel is closed.		data, in both directions, until the tunnel is closed.
	Tunnels are commonly used to create an end-to-end virtual connection,		Tunnels are commonly used to create an end-to-end virtual connection,
	through one or more proxies, which can then be secured using TLS		through one or more proxies, which can then be secured using TLS
	(Transport Layer Security, <xref target="RFC8446"/>).		(Transport Layer Security, <xref target="TLS13"/>).
	</t>		</t>
	<t>		<t>
	CONNECT uses a special form of request target, unique to this method,		CONNECT uses a special form of request target, unique to this method,
	consisting of only the host and port number of the tunnel destination,		consisting of only the host and port number of the tunnel destination,
	separated by a colon. There is no default port; a client <bcp14>MUST</bcp14> send the		separated by a colon. There is no default port; a client <bcp14>MUST</bcp14> send the
	port number even if the CONNECT request is based on a URI reference that		port number even if the CONNECT request is based on a URI reference that
	contains an authority component with an elided port		contains an authority component with an elided port
	(<xref target="uri.references"/>). For example,		(<xref target="uri.references"/>). For example,
	</t>		</t>
	<sourcecode type="http-message"><![CDATA[CONNECT server.example.c om:80 HTTP/1.1		<sourcecode type="http-message"><![CDATA[CONNECT server.example.c om:80 HTTP/1.1
	skipping to change at line 5214 ¶		skipping to change at line 5214 ¶
	</t>		</t>
	</section>		</section>
	<section anchor="TRACE" title="TRACE">		<section anchor="TRACE" title="TRACE">
	<iref primary="true" item="TRACE method"/>		<iref primary="true" item="TRACE method"/>
	<iref primary="true" item="Method" subitem="TRACE"/>		<iref primary="true" item="Method" subitem="TRACE"/>
	<t>		<t>
	The TRACE method requests a remote, application-level loop-back of the		The TRACE method requests a remote, application-level loop-back of the
	request message. The final recipient of the request <bcp14>SHOULD</bcp14> ref lect the		request message. The final recipient of the request <bcp14>SHOULD</bcp14> ref lect the
	message received, excluding some fields described below, back to the client		message received, excluding some fields described below, back to the client
	as the content of a <xref target="status.200" format="none">200 (OK)</xref> r esponse. The "message/http"		as the content of a <xref target="status.200" format="none">200 (OK)</xref> r esponse. The "message/http"
	format (<xref target="RFC9112" section="10.1"/>) is one way to do so.		format (<xref target="HTTP11" section="10.1"/>) is one way to do so.
	The final recipient is either the origin server or the first server to		The final recipient is either the origin server or the first server to
	receive a <xref target="field.max-forwards" format="none">Max-Forwards</xref> value of zero (0) in the request		receive a <xref target="field.max-forwards" format="none">Max-Forwards</xref> value of zero (0) in the request
	(<xref target="field.max-forwards"/>).		(<xref target="field.max-forwards"/>).
	</t>		</t>
	<t>		<t>
	A client <bcp14>MUST NOT</bcp14> generate fields in a TRACE request containin g		A client <bcp14>MUST NOT</bcp14> generate fields in a TRACE request containin g
	sensitive data that might be disclosed by the response. For example, it		sensitive data that might be disclosed by the response. For example, it
	would be foolish for a user agent to send stored user credentials		would be foolish for a user agent to send stored user credentials
	(<xref target="authentication"/>) or cookies <xref target="RFC6265"/> in a TR ACE		(<xref target="authentication"/>) or cookies <xref target="COOKIE"/> in a TRA CE
	request. The final recipient of the request <bcp14>SHOULD</bcp14> exclude any request		request. The final recipient of the request <bcp14>SHOULD</bcp14> exclude any request
	fields that are likely to contain sensitive data when that recipient		fields that are likely to contain sensitive data when that recipient
	generates the response content.		generates the response content.
	</t>		</t>
	<t>		<t>
	TRACE allows the client to see what is being received at the other		TRACE allows the client to see what is being received at the other
	end of the request chain and use that data for testing or diagnostic		end of the request chain and use that data for testing or diagnostic
	information. The value of the <xref target="field.via" format="none">Via</xre f> header field (<xref target="field.via"/>)		information. The value of the <xref target="field.via" format="none">Via</xre f> header field (<xref target="field.via"/>)
	is of particular interest, since it acts as a trace of the request chain.		is of particular interest, since it acts as a trace of the request chain.
	Use of the <xref target="field.max-forwards" format="none">Max-Forwards</xref > header field allows the client to		Use of the <xref target="field.max-forwards" format="none">Max-Forwards</xref > header field allows the client to
	skipping to change at line 5360 ¶		skipping to change at line 5360 ¶
	content.		content.
	</li>		</li>
	<li>		<li>
	A server that sends a <xref target="status.100" format="none">100 (Continue) </xref> response <bcp14>MUST</bcp14>		A server that sends a <xref target="status.100" format="none">100 (Continue) </xref> response <bcp14>MUST</bcp14>
	ultimately send a final status code, once it receives and processes the		ultimately send a final status code, once it receives and processes the
	request content, unless the connection is closed prematurely.		request content, unless the connection is closed prematurely.
	</li>		</li>
	<li>		<li>
	A server that responds with a final status code before reading the		A server that responds with a final status code before reading the
	entire request content <bcp14>SHOULD</bcp14> indicate whether it intends to		entire request content <bcp14>SHOULD</bcp14> indicate whether it intends to
	close the connection (e.g., see <xref target="RFC9112" section="9.6"/>) or		close the connection (e.g., see <xref target="HTTP11" section="9.6"/>) or
	continue reading the request content.		continue reading the request content.
	</li>		</li>
	</ul>		</ul>
	<!-- [rfced] Section 10.1.1. We are having difficulty parsing the		<!-- [rfced] Section 10.1.1. We are having difficulty parsing the
	following sentence. Perhaps reordering the front of the sentence		following sentence. Perhaps reordering the front of the sentence
	and using an unordered list could make it clearer?		and using an unordered list could make it clearer?
	Current:		Current:
	An origin server MUST, upon receiving an HTTP/1.1 (or later) request		An origin server MUST, upon receiving an HTTP/1.1 (or later) request
	that has a method, target URI, and complete header section that		that has a method, target URI, and complete header section that
	skipping to change at line 5488 ¶		skipping to change at line 5488 ¶
	</section>		</section>
	<section anchor="field.referer" title="Referer">		<section anchor="field.referer" title="Referer">
	<iref primary="true" item="Fields" subitem="Referer"/>		<iref primary="true" item="Fields" subitem="Referer"/>
	<iref primary="true" item="Header Fields" subitem="Referer"/>		<iref primary="true" item="Header Fields" subitem="Referer"/>
	<iref primary="true" item="Referer header field"/>		<iref primary="true" item="Referer header field"/>
	<t>		<t>
	The "Referer" [sic] header field allows the user agent to specify a URI		The "Referer" [sic] header field allows the user agent to specify a URI
	reference for the resource from which the <xref target="target.resource" form at="none">target URI</xref> was		reference for the resource from which the <xref target="target.resource" form at="none">target URI</xref> was
	obtained (i.e., the "referrer", though the field name is misspelled).		obtained (i.e., the "referrer", though the field name is misspelled).
	A user agent <bcp14>MUST NOT</bcp14> include the fragment and userinfo compon ents		A user agent <bcp14>MUST NOT</bcp14> include the fragment and userinfo compon ents
	of the URI reference <xref target="RFC3986"/>, if any, when generating the		of the URI reference <xref target="URI"/>, if any, when generating the
	Referer field value.		Referer field value.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Referer"/>		<iref primary="true" item="Grammar" subitem="Referer"/>
	<sourcecode type="abnf7230"><![CDATA[ Referer = absolute-URI / p artial-URI		<sourcecode type="abnf7230"><![CDATA[ Referer = absolute-URI / p artial-URI
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a		The field value is either an <xref target="uri.references" format="none">abso lute-URI</xref> or a
	<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),		<xref target="uri.references" format="none">partial-URI</xref>. In the latter case (<xref target="uri"/>),
	the referenced URI is relative to the target URI		the referenced URI is relative to the target URI
	(<xref target="RFC3986" sectionFormat="comma" section="5"/>).		(<xref target="URI" sectionFormat="comma" section="5"/>).
	</t>		</t>
	<t>		<t>
	The Referer header field allows servers to generate back-links to other		The Referer header field allows servers to generate back-links to other
	resources for simple analytics, logging, optimized caching, etc. It also		resources for simple analytics, logging, optimized caching, etc. It also
	allows obsolete or mistyped links to be found for maintenance. Some servers		allows obsolete or mistyped links to be found for maintenance. Some servers
	use the Referer header field as a means of denying links from other sites		use the Referer header field as a means of denying links from other sites
	(so-called "deep linking") or restricting cross-site request forgery (CSRF),		(so-called "deep linking") or restricting cross-site request forgery (CSRF),
	but not all requests contain it.		but not all requests contain it.
	</t>		</t>
	<t>		<t>
	skipping to change at line 5569 ¶		skipping to change at line 5569 ¶
	</t>		</t>
	<t>		<t>
	As described in <xref target="trailer.fields"/>,		As described in <xref target="trailer.fields"/>,
	a TE field with a "trailers" member sent in a request indicates that the		a TE field with a "trailers" member sent in a request indicates that the
	client will not discard trailer fields.		client will not discard trailer fields.
	</t>		</t>
	<t>		<t>
	TE is also used within HTTP/1.1 to advise servers about which transfer		TE is also used within HTTP/1.1 to advise servers about which transfer
	codings the client is able to accept in a response.		codings the client is able to accept in a response.
	As of publication, only HTTP/1.1 uses transfer codings		As of publication, only HTTP/1.1 uses transfer codings
	(see <xref target="RFC9112" section="7"/>).		(see <xref target="HTTP11" section="7"/>).
	</t>		</t>
	<t>		<t>
	The TE field value is a list of members, with each member (aside from		The TE field value is a list of members, with each member (aside from
	"trailers") consisting of a transfer coding name token with an optional		"trailers") consisting of a transfer coding name token with an optional
	weight indicating the client's relative preference for that		weight indicating the client's relative preference for that
	transfer coding (<xref target="quality.values"/>) and		transfer coding (<xref target="quality.values"/>) and
	optional parameters for that transfer coding.		optional parameters for that transfer coding.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="TE"/>		<iref primary="true" item="Grammar" subitem="TE"/>
	<iref primary="true" item="Grammar" subitem="t-codings"/>		<iref primary="true" item="Grammar" subitem="t-codings"/>
	skipping to change at line 5706 ¶		skipping to change at line 5706 ¶
	<t>		<t>
	The "Location" header field is used in some responses to refer to a		The "Location" header field is used in some responses to refer to a
	specific resource in relation to the response. The type of relationship is		specific resource in relation to the response. The type of relationship is
	defined by the combination of request method and status code semantics.		defined by the combination of request method and status code semantics.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="Location"/>		<iref primary="true" item="Grammar" subitem="Location"/>
	<sourcecode type="abnf7230"><![CDATA[ Location = URI-reference		<sourcecode type="abnf7230"><![CDATA[ Location = URI-reference
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The field value consists of a single URI-reference. When it has the form		The field value consists of a single URI-reference. When it has the form
	of a relative reference (<xref target="RFC3986" sectionFormat="comma" section ="4.2"/>),		of a relative reference (<xref target="URI" sectionFormat="comma" section="4. 2"/>),
	the final value is computed by resolving it against the target		the final value is computed by resolving it against the target
	URI (<xref target="RFC3986" sectionFormat="comma" section="5"/>).		URI (<xref target="URI" sectionFormat="comma" section="5"/>).
	</t>		</t>
	<t>		<t>
	For <xref target="status.201" format="none">201 (Created)</xref> responses, t he Location value refers to		For <xref target="status.201" format="none">201 (Created)</xref> responses, t he Location value refers to
	the primary resource created by the request.		the primary resource created by the request.
	For <xref target="status.3xx" format="none">3xx (Redirection)</xref> response s, the Location value refers		For <xref target="status.3xx" format="none">3xx (Redirection)</xref> response s, the Location value refers
	to the preferred target resource for automatically redirecting the request.		to the preferred target resource for automatically redirecting the request.
	</t>		</t>
	<t>		<t>
	If the Location value provided in a <xref target="status.3xx" format="none">3 xx (Redirection)</xref>		If the Location value provided in a <xref target="status.3xx" format="none">3 xx (Redirection)</xref>
	response does not have a fragment component, a user agent <bcp14>MUST</bcp14> process the		response does not have a fragment component, a user agent <bcp14>MUST</bcp14> process the
	skipping to change at line 5888 ¶		skipping to change at line 5888 ¶
	for achieving authentication via that scheme as either a		for achieving authentication via that scheme as either a
	comma-separated list of parameters or a single sequence of characters		comma-separated list of parameters or a single sequence of characters
	capable of holding base64-encoded information.		capable of holding base64-encoded information.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="token68"/>		<iref primary="true" item="Grammar" subitem="token68"/>
	<sourcecode type="abnf7230"><![CDATA[ token68 = 1*( ALPHA / DIGIT /		<sourcecode type="abnf7230"><![CDATA[ token68 = 1*( ALPHA / DIGIT /
	"-" / "." / "_" / "~" / "+" / "/" ) *"="		"-" / "." / "_" / "~" / "+" / "/" ) *"="
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The token68 syntax allows the 66 unreserved URI characters		The token68 syntax allows the 66 unreserved URI characters
	<xref target="RFC3986"/>, plus a few others, so that it can hold a		<xref target="URI"/>, plus a few others, so that it can hold a
	base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)		base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)
	encoding, with or without padding, but excluding whitespace		encoding, with or without padding, but excluding whitespace
	<xref target="RFC4648"/>.		<xref target="RFC4648"/>.
	</t>		</t>
	<t>		<t>
	Authentication parameters are name=value pairs, where the name token is		Authentication parameters are name=value pairs, where the name token is
	matched case-insensitively		matched case-insensitively
	and each parameter name <bcp14>MUST</bcp14> only occur once per challenge.		and each parameter name <bcp14>MUST</bcp14> only occur once per challenge.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="auth-param"/>		<iref primary="true" item="Grammar" subitem="auth-param"/>
	skipping to change at line 5999 ¶		skipping to change at line 5999 ¶
	</t>		</t>
	<t>		<t>
	HTTP does not restrict applications to this simple challenge-response		HTTP does not restrict applications to this simple challenge-response
	framework for access authentication. Additional mechanisms can be used,		framework for access authentication. Additional mechanisms can be used,
	such as authentication at the transport level or via message encapsulation,		such as authentication at the transport level or via message encapsulation,
	and with additional header fields specifying authentication information.		and with additional header fields specifying authentication information.
	However, such additional mechanisms are not defined by this specification.		However, such additional mechanisms are not defined by this specification.
	</t>		</t>
	<t>		<t>
	Note that various custom mechanisms for user authentication use the		Note that various custom mechanisms for user authentication use the
	Set-Cookie and Cookie header fields, defined in <xref target="RFC6265"/>,		Set-Cookie and Cookie header fields, defined in <xref target="COOKIE"/>,
	for passing tokens related to authentication.		for passing tokens related to authentication.
	</t>		</t>
	</section>		</section>
	<!-- [rfced] Section 11.5. The index entry "Origin" (note the		<!-- [rfced] Section 11.5. The index entry "Origin" (note the
	capitalization) points to this section. Should the entry be		capitalization) points to this section. Should the entry be
	lowercase?		lowercase?
	-->		-->
	<section anchor="protection.space"		<section anchor="protection.space"
	title="Establishing a Protection Space (Realm)">		title="Establishing a Protection Space (Realm)">
	<iref item="Protection Space"/>		<iref item="Protection Space"/>
	skipping to change at line 6132 ¶		skipping to change at line 6132 ¶
	<t>		<t>
	If a request is authenticated and a realm specified, the same credentials		If a request is authenticated and a realm specified, the same credentials
	are presumed to be valid for all other requests within this realm (assuming		are presumed to be valid for all other requests within this realm (assuming
	that the authentication scheme itself does not require otherwise, such as		that the authentication scheme itself does not require otherwise, such as
	credentials that vary according to a challenge value or using synchronized		credentials that vary according to a challenge value or using synchronized
	clocks).		clocks).
	</t>		</t>
	<t>		<t>
	A proxy forwarding a request <bcp14>MUST NOT</bcp14> modify any		A proxy forwarding a request <bcp14>MUST NOT</bcp14> modify any
	<xref target="field.authorization" format="none">Authorization</xref> header fields in that request.		<xref target="field.authorization" format="none">Authorization</xref> header fields in that request.
	See <xref target="RFC9111" section="3.5"/> for details of and requirements		See <xref target="CACHING" section="3.5"/> for details of and requirements
	pertaining to handling of the Authorization header field by HTTP caches.		pertaining to handling of the Authorization header field by HTTP caches.
	</t>		</t>
	</section>		</section>
	<section anchor="field.authentication-info" title="Authentication-In fo">		<section anchor="field.authentication-info" title="Authentication-In fo">
	<iref primary="true" item="Fields" subitem="Authentication-Info"/ >		<iref primary="true" item="Fields" subitem="Authentication-Info"/ >
	<iref primary="true" item="Header Fields" subitem="Authentication -Info"/>		<iref primary="true" item="Header Fields" subitem="Authentication -Info"/>
	<iref primary="true" item="Authentication-Info header field"/>		<iref primary="true" item="Authentication-Info header field"/>
	<t>		<t>
	HTTP authentication schemes can use the "Authentication-Info" response		HTTP authentication schemes can use the "Authentication-Info" response
	field to communicate information after the client's authentication credential s have been accepted.		field to communicate information after the client's authentication credential s have been accepted.
	skipping to change at line 6917 ¶		skipping to change at line 6917 ¶
	</t>		</t>
	<t>		<t>
	A Vary field containing a list of field names has two purposes:		A Vary field containing a list of field names has two purposes:
	</t>		</t>
	<ol>		<ol>
	<li>		<li>
	<t>		<t>
	To inform cache recipients that they <bcp14>MUST NOT</bcp14> use this res ponse		To inform cache recipients that they <bcp14>MUST NOT</bcp14> use this res ponse
	to satisfy a later request unless the later request has the		to satisfy a later request unless the later request has the
	same values for the listed header fields as the original request		same values for the listed header fields as the original request
	(<xref target="RFC9111" section="4.1"/>) or reuse of the		(<xref target="CACHING" section="4.1"/>) or reuse of the
	response has been validated by the origin server.		response has been validated by the origin server.
	In other words, Vary expands the cache key		In other words, Vary expands the cache key
	required to match a new request to the stored cache entry.		required to match a new request to the stored cache entry.
	</t>		</t>
	</li>		</li>
	<li>		<li>
	<t>		<t>
	To inform user agent recipients that this response was subject to		To inform user agent recipients that this response was subject to
	content negotiation (<xref target="content.negotiation"/>) and a		content negotiation (<xref target="content.negotiation"/>) and a
	different representation might be sent in a subsequent request if		different representation might be sent in a subsequent request if
	skipping to change at line 6946 ¶		skipping to change at line 6946 ¶
	subsequent requests. Generally, that is the case when the response		subsequent requests. Generally, that is the case when the response
	content has been tailored to better fit the preferences expressed by		content has been tailored to better fit the preferences expressed by
	those selecting header fields, such as when an origin server has		those selecting header fields, such as when an origin server has
	selected the response's language based on the request's		selected the response's language based on the request's
	<xref target="field.accept-language" format="none">Accept-Language</xref> hea der field.		<xref target="field.accept-language" format="none">Accept-Language</xref> hea der field.
	</t>		</t>
	<t>		<t>
	Vary might be elided when an origin server considers variance in		Vary might be elided when an origin server considers variance in
	content selection to be less significant than Vary's performance impact		content selection to be less significant than Vary's performance impact
	on caching, particularly when reuse is already limited by Cache-Control		on caching, particularly when reuse is already limited by Cache-Control
	response directives (<xref target="RFC9111" section="5.2"/>).		response directives (<xref target="CACHING" section="5.2"/>).
	</t>		</t>
	<t>		<t>
	There is no need to send the Authorization field name in Vary because		There is no need to send the Authorization field name in Vary because
	reuse of that response for a different user is prohibited by the field		reuse of that response for a different user is prohibited by the field
	definition (<xref target="field.authorization"/>).		definition (<xref target="field.authorization"/>).
	Likewise, if the response content has been selected or influenced by		Likewise, if the response content has been selected or influenced by
	network region, but the origin server wants the cached response to be		network region, but the origin server wants the cached response to be
	reused even if recipients move from one region to another, then there		reused even if recipients move from one region to another, then there
	is no need for the origin server to indicate such variance in Vary.		is no need for the origin server to indicate such variance in Vary.
	</t>		</t>
	skipping to change at line 6971 ¶		skipping to change at line 6971 ¶
	<iref item="conditional request" primary="true"/>		<iref item="conditional request" primary="true"/>
	<t>		<t>
	A conditional request is an HTTP request with one or more request header		A conditional request is an HTTP request with one or more request header
	fields that indicate a precondition to be tested before		fields that indicate a precondition to be tested before
	applying the request method to the target resource.		applying the request method to the target resource.
	<xref target="evaluation"/> defines when to evaluate preconditions and		<xref target="evaluation"/> defines when to evaluate preconditions and
	their order of precedence when more than one precondition is present.		their order of precedence when more than one precondition is present.
	</t>		</t>
	<t>		<t>
	Conditional GET requests are the most efficient mechanism for HTTP		Conditional GET requests are the most efficient mechanism for HTTP
	cache updates <xref target="RFC9111"/>. Conditionals can also be		cache updates <xref target="CACHING"/>. Conditionals can also be
	applied to state-changing methods, such as PUT and DELETE, to prevent		applied to state-changing methods, such as PUT and DELETE, to prevent
	the "lost update" problem: one client accidentally overwriting		the "lost update" problem: one client accidentally overwriting
	the work of another client that has been acting in parallel.		the work of another client that has been acting in parallel.
	</t>		</t>
	<section anchor="preconditions" title="Preconditions">		<section anchor="preconditions" title="Preconditions">
	<iref primary="false" item="selected representation"/>		<iref primary="false" item="selected representation"/>
	<t>		<t>
	Preconditions are usually defined with respect to a state of the target		Preconditions are usually defined with respect to a state of the target
	resource as a whole (its current value set) or the state as observed in a		resource as a whole (its current value set) or the state as observed in a
	previously obtained representation (one value in that set). If a resource		previously obtained representation (one value in that set). If a resource
	skipping to change at line 7006 ¶		skipping to change at line 7006 ¶
	changed since a given state known by the client. The effect of such an		changed since a given state known by the client. The effect of such an
	evaluation depends on the method semantics and choice of conditional, as		evaluation depends on the method semantics and choice of conditional, as
	defined in <xref target="evaluation"/>.		defined in <xref target="evaluation"/>.
	</t>		</t>
	<t>		<t>
	Other preconditions, defined by other specifications as extension fields,		Other preconditions, defined by other specifications as extension fields,
	might place conditions on all recipients, on the state of the target		might place conditions on all recipients, on the state of the target
	resource in general, or on a group of resources. For instance, the "If"		resource in general, or on a group of resources. For instance, the "If"
	header field in WebDAV can make a request conditional on various aspects		header field in WebDAV can make a request conditional on various aspects
	of multiple resources, such as locks, if the recipient understands and		of multiple resources, such as locks, if the recipient understands and
	implements that field (<xref target="RFC4918" sectionFormat="comma" section=" 10.4"/>).		implements that field (<xref target="WEBDAV" sectionFormat="comma" section="1 0.4"/>).
	</t>		</t>
	<t>		<t>
	Extensibility of preconditions is only possible when the precondition can		Extensibility of preconditions is only possible when the precondition can
	be safely ignored if unknown (like <xref target="field.if-modified-since" for mat="none">If-Modified-Since</xref>), when		be safely ignored if unknown (like <xref target="field.if-modified-since" for mat="none">If-Modified-Since</xref>), when
	deployment can be assumed for a given use case, or when implementation		deployment can be assumed for a given use case, or when implementation
	is signaled by some other property of the target resource. This encourages		is signaled by some other property of the target resource. This encourages
	a focus on mutually agreed deployment of common standards.		a focus on mutually agreed deployment of common standards.
	</t>		</t>
	<section anchor="field.if-match" title="If-Match">		<section anchor="field.if-match" title="If-Match">
	<iref primary="true" item="Fields" subitem="If-Match"/>		<iref primary="true" item="Fields" subitem="If-Match"/>
	skipping to change at line 7203 ¶		skipping to change at line 7203 ¶
	<t>		<t>
	An origin server that evaluates an If-None-Match condition <bcp14>MUST NOT</b cp14>		An origin server that evaluates an If-None-Match condition <bcp14>MUST NOT</b cp14>
	perform the requested method if the condition evaluates to false; instead,		perform the requested method if the condition evaluates to false; instead,
	the origin server <bcp14>MUST</bcp14> respond with either		the origin server <bcp14>MUST</bcp14> respond with either
	a) the <xref target="status.304" format="none">304 (Not Modified)</xref> stat us code if the request method		a) the <xref target="status.304" format="none">304 (Not Modified)</xref> stat us code if the request method
	is GET or HEAD or b) the <xref target="status.412" format="none">412 (Precond ition Failed)</xref> status		is GET or HEAD or b) the <xref target="status.412" format="none">412 (Precond ition Failed)</xref> status
	code for all other request methods.		code for all other request methods.
	</t>		</t>
	<t>		<t>
	Requirements on cache handling of a received If-None-Match header field		Requirements on cache handling of a received If-None-Match header field
	are defined in <xref target="RFC9111" section="4.3.2"/>.		are defined in <xref target="CACHING" section="4.3.2"/>.
	</t>		</t>
	<t>		<t>
	Note that an If-None-Match header field with a list value containing "*" and		Note that an If-None-Match header field with a list value containing "*" and
	other values (including other instances of "*") is syntactically		other values (including other instances of "*") is syntactically
	invalid (therefore not allowed to be generated) and furthermore is		invalid (therefore not allowed to be generated) and furthermore is
	unlikely to be interoperable.		unlikely to be interoperable.
	</t>		</t>
	</section>		</section>
	<section anchor="field.if-modified-since" title="If-Modified-Since">		<section anchor="field.if-modified-since" title="If-Modified-Since">
	<iref primary="true" item="Fields" subitem="If-Modified-Since"/>		<iref primary="true" item="Fields" subitem="If-Modified-Since"/>
	skipping to change at line 7310 ¶		skipping to change at line 7310 ¶
	<t>		<t>
	An origin server that evaluates an If-Modified-Since condition		An origin server that evaluates an If-Modified-Since condition
	<bcp14>SHOULD NOT</bcp14> perform the requested method if the condition evalu ates to		<bcp14>SHOULD NOT</bcp14> perform the requested method if the condition evalu ates to
	false; instead,		false; instead,
	the origin server <bcp14>SHOULD</bcp14> generate a <xref target="status.304" format="none">304 (Not Modified)</xref>		the origin server <bcp14>SHOULD</bcp14> generate a <xref target="status.304" format="none">304 (Not Modified)</xref>
	response, including only those metadata that are useful for identifying or		response, including only those metadata that are useful for identifying or
	updating a previously cached response.		updating a previously cached response.
	</t>		</t>
	<t>		<t>
	Requirements on cache handling of a received If-Modified-Since header field		Requirements on cache handling of a received If-Modified-Since header field
	are defined in <xref target="RFC9111" section="4.3.2"/>.		are defined in <xref target="CACHING" section="4.3.2"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="field.if-unmodified-since" title="If-Unmodified-Sin ce">		<section anchor="field.if-unmodified-since" title="If-Unmodified-Sin ce">
	<iref primary="true" item="Fields" subitem="If-Unmodified-Since"/ >		<iref primary="true" item="Fields" subitem="If-Unmodified-Since"/ >
	<iref primary="true" item="Header Fields" subitem="If-Unmodified- Since"/>		<iref primary="true" item="Header Fields" subitem="If-Unmodified- Since"/>
	<iref primary="true" item="If-Unmodified-Since header field"/>		<iref primary="true" item="If-Unmodified-Since header field"/>
	<t>		<t>
	The "If-Unmodified-Since" header field makes the request method conditional		The "If-Unmodified-Since" header field makes the request method conditional
	on the <xref target="selected.representation" format="none">selected represen tation</xref>'s last modification date being		on the <xref target="selected.representation" format="none">selected represen tation</xref>'s last modification date being
	earlier than or equal to the date provided in the field value.		earlier than or equal to the date provided in the field value.
	skipping to change at line 8389 ¶		skipping to change at line 8389 ¶
	The status codes listed below are defined in this specification.		The status codes listed below are defined in this specification.
	The reason phrases listed here are only recommendations -- they can be		The reason phrases listed here are only recommendations -- they can be
	replaced by local equivalents or left out altogether without affecting the		replaced by local equivalents or left out altogether without affecting the
	protocol.		protocol.
	</t>		</t>
	<t>		<t>
	Responses with status codes that are defined as heuristically cacheable		Responses with status codes that are defined as heuristically cacheable
	(e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this		(e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this
	specification) can be reused by a cache with heuristic expiration unless		specification) can be reused by a cache with heuristic expiration unless
	otherwise indicated by the method definition or explicit cache controls		otherwise indicated by the method definition or explicit cache controls
	<xref target="RFC9111"/>; all other status codes are not heuristically cachea ble.		<xref target="CACHING"/>; all other status codes are not heuristically cachea ble.
	</t>		</t>
	<t>		<t>
	Additional status codes, outside the scope of this specification, have been		Additional status codes, outside the scope of this specification, have been
	specified for use in HTTP. All such status codes ought to be registered		specified for use in HTTP. All such status codes ought to be registered
	within the "Hypertext Transfer Protocol (HTTP) Status Code Registry",		within the "Hypertext Transfer Protocol (HTTP) Status Code Registry",
	as described in <xref target="status.code.extensibility"/>.		as described in <xref target="status.code.extensibility"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="status.1xx" title="Informational 1xx">		<section anchor="status.1xx" title="Informational 1xx">
	<iref primary="true" item="1xx Informational (status code class)"/>		<iref primary="true" item="1xx Informational (status code class)"/>
	skipping to change at line 8530 ¶		skipping to change at line 8530 ¶
	Aside from responses to CONNECT, a 200 response is expected to contain		Aside from responses to CONNECT, a 200 response is expected to contain
	message content unless the message framing explicitly indicates that the		message content unless the message framing explicitly indicates that the
	content has zero length. If some aspect of the request indicates a		content has zero length. If some aspect of the request indicates a
	preference for no content upon success, the origin server ought to send a		preference for no content upon success, the origin server ought to send a
	<em>204 (No Content)</em> response instead.		<em>204 (No Content)</em> response instead.
	For CONNECT, there is no content because the successful result is a		For CONNECT, there is no content because the successful result is a
	tunnel, which begins immediately after the 200 response header section.		tunnel, which begins immediately after the 200 response header section.
	</t>		</t>
	<t>		<t>
	A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	<t>		<t>
	In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any		In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any
	available validator fields (<xref target="response.validator"/>) for the		available validator fields (<xref target="response.validator"/>) for the
	<xref target="selected.representation" format="none">selected representation< /xref>, with both a strong entity-tag and		<xref target="selected.representation" format="none">selected representation< /xref>, with both a strong entity-tag and
	a <xref target="field.last-modified" format="none">Last-Modified</xref> date being preferred.		a <xref target="field.last-modified" format="none">Last-Modified</xref> date being preferred.
	</t>		</t>
	<t>		<t>
	In 200 responses to state-changing methods, any validator fields		In 200 responses to state-changing methods, any validator fields
	(<xref target="response.validator"/>) sent in the response convey the		(<xref target="response.validator"/>) sent in the response convey the
	skipping to change at line 8600 ¶		skipping to change at line 8600 ¶
	indicates that the request was successful but the enclosed content has been		indicates that the request was successful but the enclosed content has been
	modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response		modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response
	by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the		by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the
	proxy to notify recipients when a transformation has been applied, since		proxy to notify recipients when a transformation has been applied, since
	that knowledge might impact later decisions regarding the content. For		that knowledge might impact later decisions regarding the content. For
	example, future cache validation requests for the content might only be		example, future cache validation requests for the content might only be
	applicable along the same request path (through the same proxies).		applicable along the same request path (through the same proxies).
	</t>		</t>
	<t>		<t>
	A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.204" title="204 No Content">		<section anchor="status.204" title="204 No Content">
	<iref primary="true" item="204 No Content (status code)"/>		<iref primary="true" item="204 No Content (status code)"/>
	<t>		<t>
	The <em>204 (No Content)</em> status code indicates that the server		The <em>204 (No Content)</em> status code indicates that the server
	has successfully fulfilled the request and that there is no additional		has successfully fulfilled the request and that there is no additional
	content to send in the response content. Metadata in the response		content to send in the response content. Metadata in the response
	header fields refer to the <xref target="target.resource" format="none">targe t resource</xref> and its		header fields refer to the <xref target="target.resource" format="none">targe t resource</xref> and its
	<xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied.		<xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied.
	skipping to change at line 8640 ¶		skipping to change at line 8640 ¶
	being saved remains available to the user for editing. It is also		being saved remains available to the user for editing. It is also
	frequently used with interfaces that expect automated data transfers		frequently used with interfaces that expect automated data transfers
	to be prevalent, such as within distributed version control systems.		to be prevalent, such as within distributed version control systems.
	</t>		</t>
	<t>		<t>
	A 204 response is terminated by the end of the header section;		A 204 response is terminated by the end of the header section;
	it cannot contain content or trailers.		it cannot contain content or trailers.
	</t>		</t>
	<t>		<t>
	A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.205" title="205 Reset Content">		<section anchor="status.205" title="205 Reset Content">
	<iref primary="true" item="205 Reset Content (status code)"/>		<iref primary="true" item="205 Reset Content (status code)"/>
	<t>		<t>
	The <em>205 (Reset Content)</em> status code indicates that the		The <em>205 (Reset Content)</em> status code indicates that the
	server has fulfilled the request and desires that the user agent reset the		server has fulfilled the request and desires that the user agent reset the
	"document view", which caused the request to be sent, to its original state		"document view", which caused the request to be sent, to its original state
	as received from the origin server.		as received from the origin server.
	</t>		</t>
	skipping to change at line 8726 ¶		skipping to change at line 8726 ¶
	A sender that generates a 206 response to a request with an <xref target="fie ld.if-range" format="none">If-Range</xref>		A sender that generates a 206 response to a request with an <xref target="fie ld.if-range" format="none">If-Range</xref>
	header field <bcp14>SHOULD NOT</bcp14> generate other representation header		header field <bcp14>SHOULD NOT</bcp14> generate other representation header
	fields beyond those required because the client		fields beyond those required because the client
	already has a prior response containing those header fields.		already has a prior response containing those header fields.
	Otherwise, a sender <bcp14>MUST</bcp14> generate all of the representation he ader		Otherwise, a sender <bcp14>MUST</bcp14> generate all of the representation he ader
	fields that would have been sent in a <xref target="status.200" format="none" >200 (OK)</xref> response		fields that would have been sent in a <xref target="status.200" format="none" >200 (OK)</xref> response
	to the same request.		to the same request.
	</t>		</t>
	<t>		<t>
	A 206 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 206 response is heuristically cacheable; i.e., unless otherwise indicated b y
	explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	<section anchor="partial.single" title="Single Part">		<section anchor="partial.single" title="Single Part">
	<t>		<t>
	If a single part is being transferred, the server generating the 206		If a single part is being transferred, the server generating the 206
	response <bcp14>MUST</bcp14> generate a <xref target="field.content-range" fo rmat="none">Content-Range</xref> header field,		response <bcp14>MUST</bcp14> generate a <xref target="field.content-range" fo rmat="none">Content-Range</xref> header field,
	describing what range of the selected representation is enclosed, and a		describing what range of the selected representation is enclosed, and a
	content consisting of the range. For example:		content consisting of the range. For example:
	</t>		</t>
	<sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Content		<sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Content
	Date: Wed, 15 Nov 1995 06:25:24 GMT		Date: Wed, 15 Nov 1995 06:25:24 GMT
	skipping to change at line 8905 ¶		skipping to change at line 8905 ¶
	</li>		</li>
	<li>		<li>
	Redirection to a previously stored result, as in the		Redirection to a previously stored result, as in the
	<xref target="status.304" format="none">304 (Not Modified)</xref> status cod e.		<xref target="status.304" format="none">304 (Not Modified)</xref> status cod e.
	</li>		</li>
	</ol>		</ol>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> In HTTP/1.0, the status codes <xref tar get="status.301" format="none">301 (Moved Permanently)</xref>		<strong>Note:</strong> In HTTP/1.0, the status codes <xref tar get="status.301" format="none">301 (Moved Permanently)</xref>
	and <xref target="status.302" format="none">302 (Found)</xref> were original ly defined as method-preserving		and <xref target="status.302" format="none">302 (Found)</xref> were original ly defined as method-preserving
	(<xref target="RFC1945" sectionFormat="comma" section="9.3"/>) to match thei r implementation		(<xref target="HTTP10" sectionFormat="comma" section="9.3"/>) to match their implementation
	at CERN; <xref target="status.303" format="none">303 (See Other)</xref> was defined for a redirection that		at CERN; <xref target="status.303" format="none">303 (See Other)</xref> was defined for a redirection that
	changed its method to GET. However, early user agents split on whether to		changed its method to GET. However, early user agents split on whether to
	redirect POST requests as POST (according to then-current specification)		redirect POST requests as POST (according to then-current specification)
	or as GET (the safer alternative when redirected to a different site).		or as GET (the safer alternative when redirected to a different site).
	Prevailing practice eventually converged on changing the method to GET.		Prevailing practice eventually converged on changing the method to GET.
	<xref target="status.307" format="none">307 (Temporary Redirect)</xref> and		<xref target="status.307" format="none">307 (Temporary Redirect)</xref> and
	<xref target="status.308" format="none">308 (Permanent Redirect)</xref>		<xref target="status.308" format="none">308 (Permanent Redirect)</xref>
	<xref target="RFC7538"/> were		<xref target="RFC7538"/> were
	later added to unambiguously indicate method-preserving redirects, and statu s codes		later added to unambiguously indicate method-preserving redirects, and statu s codes
	<xref target="status.301" format="none">301</xref> and <xref target="status. 302" format="none">302</xref> have been adjusted to allow a POST		<xref target="status.301" format="none">301</xref> and <xref target="status. 302" format="none">302</xref> have been adjusted to allow a POST
	skipping to change at line 9049 ¶		skipping to change at line 9049 ¶
	preferred. The user agent <bcp14>MAY</bcp14> make a selection from that list		preferred. The user agent <bcp14>MAY</bcp14> make a selection from that list
	automatically if it understands the provided media type. A specific format		automatically if it understands the provided media type. A specific format
	for automatic selection is not defined by this specification because HTTP		for automatic selection is not defined by this specification because HTTP
	tries to remain orthogonal to the definition of its content.		tries to remain orthogonal to the definition of its content.
	In practice, the representation is provided in some easily parsed format		In practice, the representation is provided in some easily parsed format
	believed to be acceptable to the user agent, as determined by shared design		believed to be acceptable to the user agent, as determined by shared design
	or content negotiation, or in some commonly accepted hypertext format.		or content negotiation, or in some commonly accepted hypertext format.
	</t>		</t>
	<t>		<t>
	A 300 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 300 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> The original proposal for the 300 st atus code defined the URI header field as		<strong>Note:</strong> The original proposal for the 300 st atus code defined the URI header field as
	providing a list of alternative representations, such that it would be		providing a list of alternative representations, such that it would be
	usable for 200, 300, and 406 responses and be transferred in responses to		usable for 200, 300, and 406 responses and be transferred in responses to
	the HEAD method. However, lack of deployment and disagreement over syntax		the HEAD method. However, lack of deployment and disagreement over syntax
	led to both URI and Alternates (a subsequent proposal) being dropped from		led to both URI and Alternates (a subsequent proposal) being dropped from
	this specification. It is possible to communicate the list as a		this specification. It is possible to communicate the list as a
	Link header field value <xref target="RFC8288"/> whose members have a relatio nship of		Link header field value <xref target="RFC8288"/> whose members have a relatio nship of
	skipping to change at line 9094 ¶		skipping to change at line 9094 ¶
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the		<strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the
	request method from POST to GET for the subsequent request. If this		request method from POST to GET for the subsequent request. If this
	behavior is undesired, the <xref target="status.308" format="none">308 (Perm anent Redirect)</xref>		behavior is undesired, the <xref target="status.308" format="none">308 (Perm anent Redirect)</xref>
	status code can be used instead.		status code can be used instead.
	</t>		</t>
	</aside>		</aside>
	<t>		<t>
	A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.302" title="302 Found">		<section anchor="status.302" title="302 Found">
	<iref primary="true" item="302 Found (status code)"/>		<iref primary="true" item="302 Found (status code)"/>
	<t>		<t>
	The <em>302 (Found)</em> status code indicates that the target		The <em>302 (Found)</em> status code indicates that the target
	resource resides temporarily under a different URI. Since the redirection		resource resides temporarily under a different URI. Since the redirection
	might be altered on occasion, the client ought to continue to use the		might be altered on occasion, the client ought to continue to use the
	target URI for future requests.		target URI for future requests.
	</t>		</t>
	skipping to change at line 9203 ¶		skipping to change at line 9203 ¶
	<t>		<t>
	Since the goal of a 304 response is to minimize information transfer		Since the goal of a 304 response is to minimize information transfer
	when the recipient already has one or more cached representations,		when the recipient already has one or more cached representations,
	a sender <bcp14>SHOULD NOT</bcp14> generate representation metadata other		a sender <bcp14>SHOULD NOT</bcp14> generate representation metadata other
	than the above listed fields unless said metadata exists for the		than the above listed fields unless said metadata exists for the
	purpose of guiding cache updates (e.g., <xref target="field.last-modified" fo rmat="none">Last-Modified</xref> might		purpose of guiding cache updates (e.g., <xref target="field.last-modified" fo rmat="none">Last-Modified</xref> might
	be useful if the response does not have an <xref target="field.etag" format=" none">ETag</xref> field).		be useful if the response does not have an <xref target="field.etag" format=" none">ETag</xref> field).
	</t>		</t>
	<t>		<t>
	Requirements on a cache that receives a 304 response are defined in		Requirements on a cache that receives a 304 response are defined in
	<xref target="RFC9111" section="4.3.4"/>. If the conditional request originat ed with an		<xref target="CACHING" section="4.3.4"/>. If the conditional request originat ed with an
	outbound client, such as a user agent with its own cache sending a		outbound client, such as a user agent with its own cache sending a
	conditional GET to a shared proxy, then the proxy <bcp14>SHOULD</bcp14> forwa rd the		conditional GET to a shared proxy, then the proxy <bcp14>SHOULD</bcp14> forwa rd the
	304 response to that client.		304 response to that client.
	</t>		</t>
	<t>		<t>
	A 304 response is terminated by the end of the header section;		A 304 response is terminated by the end of the header section;
	it cannot contain content or trailers.		it cannot contain content or trailers.
	</t>		</t>
	</section>		</section>
	<section anchor="status.305" title="305 Use Proxy">		<section anchor="status.305" title="305 Use Proxy">
	skipping to change at line 9267 ¶		skipping to change at line 9267 ¶
	</t>		</t>
	<t>		<t>
	The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the		The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the
	response containing a preferred URI reference for the new permanent URI.		response containing a preferred URI reference for the new permanent URI.
	The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection.		The user agent <bcp14>MAY</bcp14> use the Location field value for automatic redirection.
	The server's response content usually contains a short hypertext note with		The server's response content usually contains a short hypertext note with
	a hyperlink to the new URI(s).		a hyperlink to the new URI(s).
	</t>		</t>
	<t>		<t>
	A 308 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 308 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> This status code is much younger (Ju ne 2014) than its sibling codes and thus		<strong>Note:</strong> This status code is much younger (Ju ne 2014) than its sibling codes and thus
	might not be recognized everywhere. See <xref target="RFC7538" section="4"/>		might not be recognized everywhere. See <xref target="RFC7538" section="4"/>
	for deployment considerations.		for deployment considerations.
	</t>		</t>
	</aside>		</aside>
	</section>		</section>
	</section>		</section>
	skipping to change at line 9366 ¶		skipping to change at line 9366 ¶
	The <em>404 (Not Found)</em> status code indicates that the origin		The <em>404 (Not Found)</em> status code indicates that the origin
	server did not find a current representation for the		server did not find a current representation for the
	<xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one		<xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one
	exists. A 404 status code does not indicate whether this lack of representati on		exists. A 404 status code does not indicate whether this lack of representati on
	is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is		is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is
	preferred over 404 if the origin server knows, presumably through some		preferred over 404 if the origin server knows, presumably through some
	configurable means, that the condition is likely to be permanent.		configurable means, that the condition is likely to be permanent.
	</t>		</t>
	<t>		<t>
	A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.405" title="405 Method Not Allowed">		<section anchor="status.405" title="405 Method Not Allowed">
	<iref primary="true" item="405 Method Not Allowed (status code)"/ >		<iref primary="true" item="405 Method Not Allowed (status code)"/ >
	<t>		<t>
	The <em>405 (Method Not Allowed)</em> status code indicates that the		The <em>405 (Method Not Allowed)</em> status code indicates that the
	method received in the request-line is known by the origin server but		method received in the request-line is known by the origin server but
	not supported by the <xref target="target.resource" format="none">target reso urce</xref>.		not supported by the <xref target="target.resource" format="none">target reso urce</xref>.
	The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in		The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in
	a 405 response containing a list of the target resource's currently		a 405 response containing a list of the target resource's currently
	supported methods.		supported methods.
	</t>		</t>
	<t>		<t>
	A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.406" title="406 Not Acceptable">		<section anchor="status.406" title="406 Not Acceptable">
	<iref primary="true" item="406 Not Acceptable (status code)"/>		<iref primary="true" item="406 Not Acceptable (status code)"/>
	<t>		<t>
	The <em>406 (Not Acceptable)</em> status code indicates that the		The <em>406 (Not Acceptable)</em> status code indicates that the
	<xref target="target.resource" format="none">target resource</xref> does not have a current representation that		<xref target="target.resource" format="none">target resource</xref> does not have a current representation that
	would be acceptable to the user agent, according to the		would be acceptable to the user agent, according to the
	<xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request		<xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request
	(<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a		(<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a
	skipping to change at line 9473 ¶		skipping to change at line 9473 ¶
	intentionally unavailable and that the server owners desire that		intentionally unavailable and that the server owners desire that
	remote links to that resource be removed. Such an event is common for		remote links to that resource be removed. Such an event is common for
	limited-time, promotional services and for resources belonging to		limited-time, promotional services and for resources belonging to
	individuals no longer associated with the origin server's site. It is not		individuals no longer associated with the origin server's site. It is not
	necessary to mark all permanently unavailable resources as "gone" or		necessary to mark all permanently unavailable resources as "gone" or
	to keep the mark for any length of time -- that is left to the		to keep the mark for any length of time -- that is left to the
	discretion of the server owner.		discretion of the server owner.
	</t>		</t>
	<t>		<t>
	A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.411" title="411 Length Required">		<section anchor="status.411" title="411 Length Required">
	<iref primary="true" item="411 Length Required (status code)"/>		<iref primary="true" item="411 Length Required (status code)"/>
	<t>		<t>
	The <em>411 (Length Required)</em> status code indicates that the		The <em>411 (Length Required)</em> status code indicates that the
	server refuses to accept the request without a defined		server refuses to accept the request without a defined
	<xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>).		<xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>).
	The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength		The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength
	header field containing the length of the request content.		header field containing the length of the request content.
	skipping to change at line 9528 ¶		skipping to change at line 9528 ¶
	target URI is longer than the server is willing to		target URI is longer than the server is willing to
	interpret. This rare condition is only likely to occur when a client has		interpret. This rare condition is only likely to occur when a client has
	improperly converted a POST request to a GET request with long query		improperly converted a POST request to a GET request with long query
	information, when the client has descended into a "black hole" of		information, when the client has descended into a "black hole" of
	redirection (e.g., a redirected URI prefix that points to a suffix of		redirection (e.g., a redirected URI prefix that points to a suffix of
	itself) or when the server is under attack by a client attempting to		itself) or when the server is under attack by a client attempting to
	exploit potential security holes.		exploit potential security holes.
	</t>		</t>
	<t>		<t>
	A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.415" title="415 Unsupported Media Type">		<section anchor="status.415" title="415 Unsupported Media Type">
	<iref primary="true" item="415 Unsupported Media Type (status cod e)"/>		<iref primary="true" item="415 Unsupported Media Type (status cod e)"/>
	<t>		<t>
	The <em>415 (Unsupported Media Type)</em> status code indicates that		The <em>415 (Unsupported Media Type)</em> status code indicates that
	the origin server is refusing to service the request because the content is		the origin server is refusing to service the request because the content is
	in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>.		in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>.
	</t>		</t>
	<t>		<t>
	skipping to change at line 9653 ¶		skipping to change at line 9653 ¶
	acting on behalf of the origin server) sends 421 to reject a target URI		acting on behalf of the origin server) sends 421 to reject a target URI
	that does not match an <xref target="origin" format="none">origin</xref> for which the server has been		that does not match an <xref target="origin" format="none">origin</xref> for which the server has been
	configured (<xref target="origin"/>) or does not match the connection		configured (<xref target="origin"/>) or does not match the connection
	context over which the request was received		context over which the request was received
	(<xref target="routing.reject"/>).		(<xref target="routing.reject"/>).
	</t>		</t>
	<t>		<t>
	A client that receives a 421 (Misdirected Request) response <bcp14>MAY</bcp14 > retry the		A client that receives a 421 (Misdirected Request) response <bcp14>MAY</bcp14 > retry the
	request, whether or not the request method is idempotent, over a different		request, whether or not the request method is idempotent, over a different
	connection, such as a fresh connection specific to the target resource's		connection, such as a fresh connection specific to the target resource's
	origin, or via an alternative service <xref target="RFC7838"/>.		origin, or via an alternative service <xref target="ALTSVC"/>.
	</t>		</t>
	<t>		<t>
	A proxy <bcp14>MUST NOT</bcp14> generate a 421 response.		A proxy <bcp14>MUST NOT</bcp14> generate a 421 response.
	</t>		</t>
	</section>		</section>
	<section anchor="status.422" title="422 Unprocessable Content">		<section anchor="status.422" title="422 Unprocessable Content">
	<iref primary="true" item="422 Unprocessable Content (status code )"/>		<iref primary="true" item="422 Unprocessable Content (status code )"/>
	<t>		<t>
	The <em>422 (Unprocessable Content)</em> status code indicates that the serve r		The <em>422 (Unprocessable Content)</em> status code indicates that the serve r
	understands the content type of the request content (hence a		understands the content type of the request content (hence a
	skipping to change at line 9726 ¶		skipping to change at line 9726 ¶
	<section anchor="status.501" title="501 Not Implemented">		<section anchor="status.501" title="501 Not Implemented">
	<iref primary="true" item="501 Not Implemented (status code)"/>		<iref primary="true" item="501 Not Implemented (status code)"/>
	<t>		<t>
	The <em>501 (Not Implemented)</em> status code indicates that the		The <em>501 (Not Implemented)</em> status code indicates that the
	server does not support the functionality required to fulfill the request.		server does not support the functionality required to fulfill the request.
	This is the appropriate response when the server does not recognize the		This is the appropriate response when the server does not recognize the
	request method and is not capable of supporting it for any resource.		request method and is not capable of supporting it for any resource.
	</t>		</t>
	<t>		<t>
	A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y		A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y
	the method definition or explicit cache controls (see <xref target="RFC9111" section="4.2.2"/>).		the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="status.502" title="502 Bad Gateway">		<section anchor="status.502" title="502 Bad Gateway">
	<iref primary="true" item="502 Bad Gateway (status code)"/>		<iref primary="true" item="502 Bad Gateway (status code)"/>
	<t>		<t>
	The <em>502 (Bad Gateway)</em> status code indicates that the server,		The <em>502 (Bad Gateway)</em> status code indicates that the server,
	while acting as a gateway or proxy, received an invalid response from an		while acting as a gateway or proxy, received an invalid response from an
	inbound server it accessed while attempting to fulfill the request.		inbound server it accessed while attempting to fulfill the request.
	</t>		</t>
	</section>		</section>
	skipping to change at line 9785 ¶		skipping to change at line 9785 ¶
	</t>		</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="extending" title="Extending HTTP">		<section anchor="extending" title="Extending HTTP">
	<t>		<t>
	HTTP defines a number of generic extension points that can be used to		HTTP defines a number of generic extension points that can be used to
	introduce capabilities to the protocol without introducing a new version,		introduce capabilities to the protocol without introducing a new version,
	including methods, status codes, field names, and further extensibility		including methods, status codes, field names, and further extensibility
	points within defined fields, such as authentication schemes and		points within defined fields, such as authentication schemes and
	cache directives (see Cache-Control extensions in <xref target="RFC9111" sect ion="5.2.3"/>). Because the semantics of HTTP are		cache directives (see Cache-Control extensions in <xref target="CACHING" sect ion="5.2.3"/>). Because the semantics of HTTP are
	not versioned, these extension points are persistent; the version of the		not versioned, these extension points are persistent; the version of the
	protocol in use does not affect their semantics.		protocol in use does not affect their semantics.
	</t>		</t>
	<t>		<t>
	Version-independent extensions are discouraged from depending on or		Version-independent extensions are discouraged from depending on or
	interacting with the specific version of the protocol in use. When this is		interacting with the specific version of the protocol in use. When this is
	unavoidable, careful consideration needs to be given to how the extension		unavoidable, careful consideration needs to be given to how the extension
	can interoperate across versions.		can interoperate across versions.
	</t>		</t>
	<!-- [rfced] Section 16. In the sentence below, should		<!-- [rfced] Section 16. In the sentence below, should
	"transfer-codings" be "transfer encodings" or "transfer codings"?		"transfer-codings" be "transfer encodings" or "transfer codings"?
	Current:		Current:
	Additionally, specific versions of HTTP might have their own		Additionally, specific versions of HTTP might have their own
	extensibility points, such as transfer-codings in HTTP/1.1		extensibility points, such as transfer-codings in HTTP/1.1
	-->		-->
	<t>		<t>
	Additionally, specific versions of HTTP might have their own extensibility		Additionally, specific versions of HTTP might have their own extensibility
	points, such as transfer-codings in HTTP/1.1 (<xref target="RFC9112" section=		points, such as transfer-codings in HTTP/1.1 (<xref target="HTTP11" section="
	"6.1"/>) and HTTP/2		6.1"/>) and HTTP/2
	SETTINGS or frame types <xref target="RFC7540"/>. These extension points are		SETTINGS or frame types <xref target="HTTP2"/>. These extension points are sp
	specific to the		ecific to the
	version of the protocol they occur within.		version of the protocol they occur within.
	</t>		</t>
	<t>		<t>
	Version-specific extensions cannot override or modify the semantics of		Version-specific extensions cannot override or modify the semantics of
	a version-independent mechanism or extension point (like a method or		a version-independent mechanism or extension point (like a method or
	header field) without explicitly being allowed by that protocol element. For		header field) without explicitly being allowed by that protocol element. For
	example, the CONNECT method (<xref target="CONNECT"/>) allows this.		example, the CONNECT method (<xref target="CONNECT"/>) allows this.
	</t>		</t>
	<t>		<t>
	These guidelines assure that the protocol operates correctly and		These guidelines assure that the protocol operates correctly and
	skipping to change at line 9975 ¶		skipping to change at line 9975 ¶
	which it occurs has explicit freshness information; however,		which it occurs has explicit freshness information; however,
	a status code defined as heuristically cacheable is allowed to		a status code defined as heuristically cacheable is allowed to
	be cached without explicit freshness information.		be cached without explicit freshness information.
	-->		-->
	<t>		<t>
	The definition of a new final status code ought to specify whether or not it is		The definition of a new final status code ought to specify whether or not it is
	heuristically cacheable. Note that all final status codes can be cached if th e response they		heuristically cacheable. Note that all final status codes can be cached if th e response they
	occur in has explicit freshness information; however, those status codes that are		occur in has explicit freshness information; however, those status codes that are
	defined as being heuristically cacheable are allowed to be cached without exp licit		defined as being heuristically cacheable are allowed to be cached without exp licit
	freshness information. Likewise, the definition of a status code can place		freshness information. Likewise, the definition of a status code can place
	constraints upon cache behavior if the "must-understand" cache directive is u sed. See <xref target="RFC9111"/> for more information.		constraints upon cache behavior if the "must-understand" cache directive is u sed. See <xref target="CACHING"/> for more information.
	</t>		</t>
	<t>		<t>
	Finally, the definition of a new status code ought to indicate whether the		Finally, the definition of a new status code ought to indicate whether the
	content has any implied association with an identified resource (<xref target ="identifying.content"/>).		content has any implied association with an identified resource (<xref target ="identifying.content"/>).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="fields.extensibility" title="Field Extensibility">		<section anchor="fields.extensibility" title="Field Extensibility">
	<t>		<t>
	HTTP's most widely used extensibility point is the definition of new header an d		HTTP's most widely used extensibility point is the definition of new header an d
	skipping to change at line 10305 ¶		skipping to change at line 10305 ¶
	<t>		<t>
	Authentication schemes need to document whether they are usable in		Authentication schemes need to document whether they are usable in
	origin-server authentication (i.e., using <xref target="field.www-authenti cate" format="none">WWW-Authenticate</xref>),		origin-server authentication (i.e., using <xref target="field.www-authenti cate" format="none">WWW-Authenticate</xref>),
	and/or proxy authentication (i.e., using <xref target="field.proxy-authent icate" format="none">Proxy-Authenticate</xref>).		and/or proxy authentication (i.e., using <xref target="field.proxy-authent icate" format="none">Proxy-Authenticate</xref>).
	</t>		</t>
	</li>		</li>
	<li>		<li>
	<t>		<t>
	The credentials carried in an <xref target="field.authorization" format="n one">Authorization</xref> header field are specific to		The credentials carried in an <xref target="field.authorization" format="n one">Authorization</xref> header field are specific to
	the user agent and, therefore, have the same effect on HTTP caches as the		the user agent and, therefore, have the same effect on HTTP caches as the
	"private" Cache-Control response directive (<xref target="RFC9111" section ="5.2.2.7"/>),		"private" Cache-Control response directive (<xref target="CACHING" section ="5.2.2.7"/>),
	within the scope of the request in which they appear.		within the scope of the request in which they appear.
	</t>		</t>
	<t>		<t>
	Therefore, new authentication schemes that choose not to carry		Therefore, new authentication schemes that choose not to carry
	credentials in the <xref target="field.authorization" format="none">Author ization</xref> header field (e.g., using a newly defined		credentials in the <xref target="field.authorization" format="none">Author ization</xref> header field (e.g., using a newly defined
	header field) will need to explicitly disallow caching, by mandating the u se of		header field) will need to explicitly disallow caching, by mandating the u se of
	Cache-Control response directives (e.g., "private").		Cache-Control response directives (e.g., "private").
	</t>		</t>
	</li>		</li>
	<li>		<li>
	skipping to change at line 10456 ¶		skipping to change at line 10456 ¶
	This will normally only be used in the case when a		This will normally only be used in the case when a
	responsible party cannot be contacted.</li>		responsible party cannot be contacted.</li>
	</ol>		</ol>
	</section>		</section>
	</section>		</section>
	<section anchor="security.considerations" title="Security Considerations">		<section anchor="security.considerations" title="Security Considerations">
	<t>		<t>
	This section is meant to inform developers, information providers, and		This section is meant to inform developers, information providers, and
	users of known security concerns relevant to HTTP semantics and its		users of known security concerns relevant to HTTP semantics and its
	use for transferring information over the Internet. Considerations related		use for transferring information over the Internet. Considerations related
	to caching are discussed in <xref target="RFC9111" section="7"/>,		to caching are discussed in <xref target="CACHING" section="7"/>,
	and considerations related to HTTP/1.1 message syntax and parsing are		and considerations related to HTTP/1.1 message syntax and parsing are
	discussed in <xref target="RFC9112" section="11"/>.		discussed in <xref target="HTTP11" section="11"/>.
	</t>		</t>
	<t>		<t>
	The list of considerations below is not exhaustive. Most security concerns		The list of considerations below is not exhaustive. Most security concerns
	related to HTTP semantics are about securing server-side applications (code		related to HTTP semantics are about securing server-side applications (code
	behind the HTTP interface), securing user agent processing of content		behind the HTTP interface), securing user agent processing of content
	received via HTTP, or secure use of the Internet in general, rather than		received via HTTP, or secure use of the Internet in general, rather than
	security of the protocol. The security considerations for URIs, which		security of the protocol. The security considerations for URIs, which
	are fundamental to HTTP operation, are discussed in		are fundamental to HTTP operation, are discussed in
	<xref target="RFC3986" section="7"/>. Various organizations maintain		<xref target="URI" section="7"/>. Various organizations maintain
	topical information and links to current research on Web application		topical information and links to current research on Web application
	security (e.g., <xref target="OWASP"/>).		security (e.g., <xref target="OWASP"/>).
	</t>		</t>
	<section anchor="establishing.authority" title="Establishing Authority" >		<section anchor="establishing.authority" title="Establishing Authority" >
	<iref item="authoritative response" primary="true"/>		<iref item="authoritative response" primary="true"/>
	<iref item="phishing" primary="true"/>		<iref item="phishing" primary="true"/>
	<t>		<t>
	HTTP relies on the notion of an <em>authoritative response</em>: a		HTTP relies on the notion of an <em>authoritative response</em>: a
	response that has been determined by (or at the direction of) the origin		response that has been determined by (or at the direction of) the origin
	server identified within the target URI to be the most appropriate response		server identified within the target URI to be the most appropriate response
	skipping to change at line 10509 ¶		skipping to change at line 10509 ¶
	The "https" scheme (<xref target="https.uri"/>) is intended to prevent		The "https" scheme (<xref target="https.uri"/>) is intended to prevent
	(or at least reveal) many of these potential attacks on establishing		(or at least reveal) many of these potential attacks on establishing
	authority, provided that the negotiated connection is secured and		authority, provided that the negotiated connection is secured and
	the client properly verifies that the communicating server's identity		the client properly verifies that the communicating server's identity
	matches the target URI's authority component		matches the target URI's authority component
	(<xref target="https.verify"/>). Correctly implementing such verification		(<xref target="https.verify"/>). Correctly implementing such verification
	can be difficult (see <xref target="Georgiev"/>).		can be difficult (see <xref target="Georgiev"/>).
	</t>		</t>
	<t>		<t>
	Authority for a given origin server can be delegated through protocol		Authority for a given origin server can be delegated through protocol
	extensions; for example, <xref target="RFC7838"/>. Likewise, the set of		extensions; for example, <xref target="ALTSVC"/>. Likewise, the set of
	servers for which a connection is considered authoritative can be changed		servers for which a connection is considered authoritative can be changed
	with a protocol extension like <xref target="RFC8336"/>.		with a protocol extension like <xref target="RFC8336"/>.
	</t>		</t>
	<t>		<t>
	Providing a response from a non-authoritative source, such as a shared		Providing a response from a non-authoritative source, such as a shared
	proxy cache, is often useful to improve performance and availability, but		proxy cache, is often useful to improve performance and availability, but
	only to the extent that the source can be trusted or the distrusted		only to the extent that the source can be trusted or the distrusted
	response can be safely used.		response can be safely used.
	</t>		</t>
	<t>		<t>
	skipping to change at line 10547 ¶		skipping to change at line 10547 ¶
	and privacy problems. Intermediaries might have access to security-related		and privacy problems. Intermediaries might have access to security-related
	information, personal information about individual users and		information, personal information about individual users and
	organizations, and proprietary information belonging to users and		organizations, and proprietary information belonging to users and
	content providers. A compromised intermediary, or an intermediary		content providers. A compromised intermediary, or an intermediary
	implemented or configured without regard to security and privacy		implemented or configured without regard to security and privacy
	considerations, might be used in the commission of a wide range of		considerations, might be used in the commission of a wide range of
	potential attacks.		potential attacks.
	</t>		</t>
	<t>		<t>
	Intermediaries that contain a shared cache are especially vulnerable		Intermediaries that contain a shared cache are especially vulnerable
	to cache poisoning attacks, as described in <xref target="RFC9111" section="7 "/>.		to cache poisoning attacks, as described in <xref target="CACHING" section="7 "/>.
	</t>		</t>
	<t>		<t>
	Implementers need to consider the privacy and security		Implementers need to consider the privacy and security
	implications of their design and coding decisions, and of the		implications of their design and coding decisions, and of the
	configuration options they provide to operators (especially the		configuration options they provide to operators (especially the
	default configuration).		default configuration).
	</t>		</t>
	<t>		<t>
	Intermediaries are no more trustworthy than the people and policies		Intermediaries are no more trustworthy than the people and policies
	under which they operate; HTTP cannot solve this problem.		under which they operate; HTTP cannot solve this problem.
	skipping to change at line 10671 ¶		skipping to change at line 10671 ¶
	<t>		<t>
	HTTP messages can be compressed in a number of ways, including using TLS		HTTP messages can be compressed in a number of ways, including using TLS
	compression, content codings, transfer codings, and other extension or		compression, content codings, transfer codings, and other extension or
	version-specific mechanisms.		version-specific mechanisms.
	</t>		</t>
	<t>		<t>
	The most effective mitigation for this risk is to disable compression on		The most effective mitigation for this risk is to disable compression on
	sensitive data, or to strictly separate sensitive data from attacker-controll ed		sensitive data, or to strictly separate sensitive data from attacker-controll ed
	data so that they cannot share the same compression dictionary. With		data so that they cannot share the same compression dictionary. With
	careful design, a compression scheme can be designed in a way that is not		careful design, a compression scheme can be designed in a way that is not
	considered exploitable in limited use cases, such as HPACK <xref target="RFC7 541"/>.		considered exploitable in limited use cases, such as HPACK <xref target="HPAC K"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="personal.information"		<section anchor="personal.information"
	title="Disclosure of Personal Information">		title="Disclosure of Personal Information">
	<t>		<t>
	Clients are often privy to large amounts of personal information,		Clients are often privy to large amounts of personal information,
	including both information provided by the user to interact with resources		including both information provided by the user to interact with resources
	(e.g., the user's name, location, mail address, passwords, encryption		(e.g., the user's name, location, mail address, passwords, encryption
	keys, etc.) and information about the user's browsing activity over		keys, etc.) and information about the user's browsing activity over
	time (e.g., history, bookmarks, etc.). Implementations need to		time (e.g., history, bookmarks, etc.). Implementations need to
	skipping to change at line 10778 ¶		skipping to change at line 10778 ¶
	which might lead to some confusion if an application mistakenly reads the		which might lead to some confusion if an application mistakenly reads the
	protocol-specific meta-variable instead of the default one. (This historical practice		protocol-specific meta-variable instead of the default one. (This historical practice
	is why <xref target="considerations.for.new.field.names"/> discourages the cr eation		is why <xref target="considerations.for.new.field.names"/> discourages the cr eation
	of new field names that contain an underscore.)		of new field names that contain an underscore.)
	</t>		</t>
	<t>		<t>
	Unfortunately, mapping field names to different interface names can lead to		Unfortunately, mapping field names to different interface names can lead to
	security vulnerabilities if the mapping is incomplete or ambiguous. For examp le,		security vulnerabilities if the mapping is incomplete or ambiguous. For examp le,
	if an attacker were to send a field named "Transfer_Encoding", a naive interf ace		if an attacker were to send a field named "Transfer_Encoding", a naive interf ace
	might map that to the same variable name as the "Transfer-Encoding" field, re sulting		might map that to the same variable name as the "Transfer-Encoding" field, re sulting
	in a potential request smuggling vulnerability (<xref target="RFC9112" sectio n="11.2"/>).		in a potential request smuggling vulnerability (<xref target="HTTP11" section ="11.2"/>).
	</t>		</t>
	<t>		<t>
	To mitigate the associated risks, implementations that perform such		To mitigate the associated risks, implementations that perform such
	mappings are advised to make the mapping unambiguous and complete		mappings are advised to make the mapping unambiguous and complete
	for the full range of potential octets received as a name (including those		for the full range of potential octets received as a name (including those
	that are discouraged or forbidden by the HTTP grammar).		that are discouraged or forbidden by the HTTP grammar).
	For example, a field with an unusual name character might		For example, a field with an unusual name character might
	result in the request being blocked, the specific field being removed,		result in the request being blocked, the specific field being removed,
	or the name being passed with a different prefix to distinguish it from		or the name being passed with a different prefix to distinguish it from
	other fields.		other fields.
	skipping to change at line 12071 ¶		skipping to change at line 12071 ¶
	<td>		<td>
	<xref target="protocol.version" format="counter"/>		<xref target="protocol.version" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="HTTP10" to="HTTP/1.0"/>
	<displayreference target="RFC9111" to="CACHING"/>		<displayreference target="HTTP11" to="HTTP/1.1"/>
	<displayreference target="RFC0793" to="TCP"/>		<displayreference target="HTTP2" to="HTTP/2"/>
	<displayreference target="RFC8446" to="TLS13"/>		<displayreference target="HTTP3" to="HTTP/3"/>
	<displayreference target="RFC3986" to="URI"/>
	<displayreference target="RFC7838" to="ALTSVC"/>
	<displayreference target="RFC6265" to="COOKIE"/>
	<displayreference target="RFC7541" to="HPACK"/>
	<displayreference target="RFC1945" to="HTTP/1.0"/>
	<displayreference target="RFC9112" to="HTTP/1.1"/>
	<displayreference target="RFC7540" to="HTTP/2"/>
	<displayreference target="RFC9113" to="HTTP/3"/>
	<displayreference target="RFC4918" to="WEBDAV"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<!-- [I-D.ietf-httpbis-cache] in EDIT state as of 09/29/21; companion document R		<!-- [I-D.ietf-httpbis-cache]; companion document RFC 9111 -->
	FC 9111		<reference anchor='CACHING' target='https://www.rfc-editor.org/info/r
			fc9111'>
	-->		<front>
			<title>HTTP Caching</title>
	<reference anchor='RFC9111' target='https://www.rfc-editor.org/info/rfc9111'>		<author initials='R' surname='Fielding' fullname='Roy Fielding'
	<front>		role='editor'>
	<title>HTTP Caching</title>		<organization />
	<author initials='R' surname='Fielding' fullname='Roy Fielding' role='edit		</author>
	or'>		<author initials='M' surname='Nottingham' fullname='Mark Nottin
	<organization />		gham' role='editor'>
	</author>		<organization />
	<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role=		</author>
	'editor'>		<author initials='J' surname='Reschke' fullname='Julian Reschke
	<organization />		' role='editor'>
	</author>		<organization />
	<author initials='J' surname='Reschke' fullname='Julian Reschke' role='edi		</author>
	tor'>		<date year='2022' month='January' />
	<organization />		</front>
	</author>		<seriesInfo name="RFC" value="9111"/>
	<date year='2022' month='January' />		<seriesInfo name="DOI" value="10.17487/RFC9111"/>
	</front>		</reference>
	<seriesInfo name="RFC" value="9111"/>
	<seriesInfo name="DOI" value="10.17487/RFC9111"/>
	</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
	xml"/>		<reference anchor="URI" target="https://www.rfc-editor.org/info/rfc3
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.		986">
	xml"/>		<front>
			<title abbrev="URI Generic Syntax">Uniform Resource Identifier
			(URI): Generic Syntax</title>
			<author initials="T." surname="Berners-Lee" fullname="Tim Bern
			ers-Lee"/>
			<author initials="R." surname="Fielding" fullname="Roy T. Fiel
			ding"/>
			<author initials="L." surname="Masinter" fullname="Larry Masin
			ter"/>
			<date month="January" year="2005"/>
			</front>
			<seriesInfo name="STD" value="66"/>
			<seriesInfo name="RFC" value="3986"/>
			<seriesInfo name="DOI" value="10.17487/RFC3986"/>
			</reference>
			<reference anchor="TCP" target="https://www.rfc-editor.org/info/rfc7
			93">
			<front>
			<title>Transmission Control Protocol</title>
			<author initials="J." surname="Postel" fullname="Jon Postel"/>
			<date year="1981" month="September"/>
			</front>
			<seriesInfo name="STD" value="7"/>
			<seriesInfo name="RFC" value="793"/>
			<seriesInfo name="DOI" value="10.17487/RFC0793"/>
			</reference>
	<!-- [rfced] FYI - xml2rfc is not generating the reference for RFC		<!-- [rfced] FYI - xml2rfc is not generating the reference for RFC
	4647 correctly. Both authors are actually editors. We have		4647 correctly. Both authors are actually editors. We have
	included the full reference in the XML instead.		included the full reference in the XML instead.
	As produced by the xi:include:		As produced by the xi:include:
	[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",		[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
	BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,		BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,
	<https://www.rfc-editor.org/info/rfc4647>.		<https://www.rfc-editor.org/info/rfc4647>.
	Current:		Current:
	skipping to change at line 12154 ¶		skipping to change at line 12163 ¶
	<seriesInfo name="DOI" value="10.17487/RFC4647"/>		<seriesInfo name="DOI" value="10.17487/RFC4647"/>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6365. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6365. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
	xml"/>		<reference anchor="TLS13" target="https://www.rfc-editor.org/info/rf
			c8446">
			<front>
			<title>The Transport Layer Security (TLS) Protocol Version 1.3
			</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescor
			la"/>
			<date year="2018" month="August"/>
			</front>
			<seriesInfo name="RFC" value="8446"/>
			<seriesInfo name="DOI" value="10.17487/RFC8446"/>
			</reference>
	<reference anchor="USASCII">		<reference anchor="USASCII">
	<front>		<front>
	<title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>		<title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
	<author>		<author>
	<organization>American National Standards Institute</organi zation>		<organization>American National Standards Institute</organi zation>
	</author>		</author>
	<date year="1986"/>		<date year="1986"/>
	</front>		</front>
	<seriesInfo name="ANSI" value="X3.4"/>		<seriesInfo name="ANSI" value="X3.4"/>
	skipping to change at line 12188 ¶		skipping to change at line 12206 ¶
	<seriesInfo name="DOI" value="10.1109/MC.1984.1659158"/>		<seriesInfo name="DOI" value="10.1109/MC.1984.1659158"/>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280. xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<!-- [HTTP11] [I-D.ietf-httpbis-messaging]; companion document RFC 9112 -->		<!-- [HTTP11] [I-D.ietf-httpbis-messaging]; companion document RFC 9112 -->
			<reference anchor="HTTP11" target='https://www.rfc-editor.org/info/r
	<reference anchor="RFC9112" target='https://www.rfc-editor.org/info/rfc9112'>		fc9112'>
	<front>		<front>
	<title>HTTP/1.1</title>		<title>HTTP/1.1</title>
	<author initials="R." fullname="Roy Fielding" role="editor">		<author initials="R." fullname="Roy Fielding" role="editor">
	<organization>Adobe</organization>		<organization>Adobe</organization>
	</author>		</author>
	<author fullname="Mark Nottingham" role="editor">		<author fullname="Mark Nottingham" role="editor">
	<organization>Fastly</organization>		<organization>Fastly</organization>
	</author>		</author>
	<author fullname="Julian Reschke" role="editor">		<author fullname="Julian Reschke" role="editor">
	<organization>greenbytes GmbH</organization>		<organization>greenbytes GmbH</organization>
	</author>		</author>
	<date month="January" year="2022"/>		<date month="January" year="2022"/>
	</front>		</front>
	<seriesInfo name="RFC" value="9112"/>		<seriesInfo name="RFC" value="9112"/>
	<seriesInfo name="DOI" value="10.17487/RFC9112"/>		<seriesInfo name="DOI" value="10.17487/RFC9112"/>
	</reference>		</reference>
	<reference anchor="Err1912"		<reference anchor="Err1912"
	target="https://www.rfc-editor.org/errata/eid1912"		target="https://www.rfc-editor.org/errata/eid1912"
	quote-title="false">		quote-title="false">
	<front>		<front>
	<title>Erratum ID 1912</title>		<title>Erratum ID 1912</title>
	<author>		<author>
	<organization>RFC Errata</organization>		<organization>RFC Errata</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	skipping to change at line 12316 ¶		skipping to change at line 12332 ¶
	<reference anchor="REST" target="https://roy.gbiv.com/pubs/dissertat ion/top.htm">		<reference anchor="REST" target="https://roy.gbiv.com/pubs/dissertat ion/top.htm">
	<front>		<front>
	<title>Architectural Styles and the Design of Network-based So ftware Architectures</title>		<title>Architectural Styles and the Design of Network-based So ftware Architectures</title>
	<author initials="R.T." surname="Fielding" fullname="Roy T. Fi elding"/>		<author initials="R.T." surname="Fielding" fullname="Roy T. Fi elding"/>
	<date month="September" year="2000"/>		<date month="September" year="2000"/>
	</front>		</front>
	<refcontent>Doctoral Dissertation, University of California, Irvi ne</refcontent>		<refcontent>Doctoral Dissertation, University of California, Irvi ne</refcontent>
	</reference>		</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1919. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1919. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1945.		<reference anchor="HTTP10" target="https://www.rfc-editor.org/info/r
	xml"/>		fc1945">
			<front>
			<title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1
			.0</title>
			<author initials="T." surname="Berners-Lee" fullname="T. Berne
			rs-Lee"/>
			<author initials="R." surname="Fielding" fullname="R. Fielding
			"/>
			<author initials="H." surname="Frystyk" fullname="H. Frystyk"/
			>
			<date month="May" year="1996"/>
			</front>
			<seriesInfo name="RFC" value="1945"/>
			<seriesInfo name="DOI" value="10.17487/RFC1945"/>
			</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2047. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2047. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2068. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2068. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2145. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2145. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2295. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2295. xml"/>
	<!-- long way to include the Day attribute because this is an April 1st RFC -->		<!-- long way to include the Day attribute because this is an April 1st RFC -->
	<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/rfc2324">		<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/
	<front>		rfc2324">
	<title>		<front>
	Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)		<title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</ti
	</title>		tle>
	<author initials="L." surname="Masinter" fullname="L. Masinter">		<author initials="L." surname="Masinter" fullname="L. Masinter
	<organization/>		"/>
	</author>		<date year="1998" month="April" day="1"/>
	<date year="1998" month="April" day="1"/>		</front>
	</front>		<seriesInfo name="RFC" value="2324"/>
	<seriesInfo name="RFC" value="2324"/>		<seriesInfo name="DOI" value="10.17487/RFC2324"/>
	<seriesInfo name="DOI" value="10.17487/RFC2324"/>		</reference>
	</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2616. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2616. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2617. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2617. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2774. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2774. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2978. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2978. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3040. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3040. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4559. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4559. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4918.		<reference anchor="WEBDAV" target="https://www.rfc-editor.org/info/r
	xml"/>		fc4918">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.		<front>
	xml"/>		<title>HTTP Extensions for Web Distributed Authoring and Versi
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7541.		oning (WebDAV)</title>
	xml"/>		<author initials="L." surname="Dusseault" fullname="L. Dusseau
			lt" role="editor"/>
			<date month="June" year="2007"/>
			</front>
			<seriesInfo name="RFC" value="4918"/>
			<seriesInfo name="DOI" value="10.17487/RFC4918"/>
			</reference>
			<reference anchor="HTTP2" target="https://www.rfc-editor.org/info/rf
			c7540">
			<front>
			<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
			<author initials="M." surname="Belshe" fullname="M. Belshe"/>
			<author initials="R." surname="Peon" fullname="R. Peon"/>
			<author initials="M."
			surname="Thomson"
			fullname="M. Thomson"
			role="editor"/>
			<date year="2015" month="May"/>
			</front>
			<seriesInfo name="RFC" value="7540"/>
			<seriesInfo name="DOI" value="10.17487/RFC7540"/>
			</reference>
			<reference anchor="HPACK" target="https://www.rfc-editor.org/info/rf
			c7541">
			<front>
			<title>HPACK: Header Compression for HTTP/2</title>
			<author initials="R." surname="Peon" fullname="R. Peon"/>
			<author initials="H." surname="Ruellan" fullname="H. Ruellan"/
			>
			<date year="2015" month="May"/>
			</front>
			<seriesInfo name="RFC" value="7541"/>
			<seriesInfo name="DOI" value="10.17487/RFC7541"/>
			</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7232. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7232. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7233. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7233. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7235. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7235. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7578. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7578. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7615. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7615. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7838.		<reference anchor="ALTSVC" target="https://www.rfc-editor.org/info/r
	xml"/>		fc7838">
			<front>
			<title>HTTP Alternative Services</title>
			<author initials="M." surname="Nottingham" fullname="M. Nottin
			gham"/>
			<author initials="P." surname="McManus" fullname="P. McManus"/
			>
			<author initials="J." surname="Reschke" fullname="J. Reschke"/
			>
			<date year="2016" month="April"/>
			</front>
			<seriesInfo name="RFC" value="7838"/>
			<seriesInfo name="DOI" value="10.17487/RFC7838"/>
			</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8336. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8336. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615. xml"/>
	<!-- [HTTP3][I-D.ietf-quic-http] in RFC-EDIOTR*R state as of 12/17/21; companion document RFC 9113 -->		<!-- [HTTP3][I-D.ietf-quic-http] in RFC-EDITOR*R state as of 1/6/2022; companion document RFC 9113 -->
	<!--[rfced] FYI - we have updated the reference for I-D.ietf-quic-http		<!--[rfced] FYI - we have updated the reference for I-D.ietf-quic-http
	to point to RFC-to-be 9113. Note that keeping the reference in		to point to RFC-to-be 9113. Note that keeping the reference in
	that form will depend on that document's movement through our		that form will depend on that document's movement through our
	queue. If not ready to be published simultaneously with this		queue. If not ready to be published simultaneously with this
	document, we will revert to pointing to the I-D form.-->		document, we will revert to pointing to the I-D form.-->
			<reference anchor='HTTP3' target='https://www.rfc-editor.org/info/rf
	<reference anchor='RFC9113' target='https://www.rfc-editor.org/info/rfc9113'>		c9113'>
	<front>		<front>
	<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>		<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
	<author initials='M' surname='Bishop' fullname='Mike Bishop' role="editor">		<author initials='M' surname='Bishop' fullname='Mike Bishop' r
	<organization />		ole="editor">
	</author>		<organization />
	<date year='2022' month='January' />		</author>
	</front>		<date year='2022' month='January' />
	<seriesInfo name="RFC" value="9113"/>		</front>
	<seriesInfo name="DOI" value="10.17487/RFC9113"/>		<seriesInfo name="RFC" value="9113"/>
	</reference>		<seriesInfo name="DOI" value="10.17487/RFC9113"/>
			</reference>
	<!-- [rfced] Section 8.3.1 and Informative References. The current		<!-- [rfced] Section 8.3.1 and Informative References. The current
	reference entry in this document for [BCP13] includes only RFC		reference entry in this document for [BCP13] includes only RFC
	6838. However, BCP 13 also includes RFC 4289. Should the		6838. However, BCP 13 also includes RFC 4289. Should the
	reference include both RFCs? Or should [BCP13] be changed to		reference include both RFCs? Or should [BCP13] be changed to
	[RFC6838]?		[RFC6838]?
	Current:		Current:
	Media types ought to be registered with IANA according to the		Media types ought to be registered with IANA according to the
	procedures defined in [BCP13].		procedures defined in [BCP13].
	skipping to change at line 12439 ¶		skipping to change at line 12499 ¶
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe rence.RFC.7595.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe rence.RFC.7595.xml"/>
	</referencegroup>		</referencegroup>
	<referencegroup anchor="BCP178" target="https://www.rfc-editor.org/i nfo/bcp178">		<referencegroup anchor="BCP178" target="https://www.rfc-editor.org/i nfo/bcp178">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe rence.RFC.6648.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refe rence.RFC.6648.xml"/>
	</referencegroup>		</referencegroup>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3864. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3864. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3875. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3875. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5789. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5789. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.		<reference anchor="COOKIE" target="https://www.rfc-editor.org/info/r
	xml"/>		fc6265">
			<front>
			<title>HTTP State Management Mechanism</title>
			<author initials="A." surname="Barth" fullname="Adam Barth"/>
			<date year="2011" month="April"/>
			</front>
			<seriesInfo name="RFC" value="6265"/>
			<seriesInfo name="DOI" value="10.17487/RFC6265"/>
			</reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6585. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6585. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7538. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7538. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7694. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7694. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8187. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8187. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8246. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8246. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8288. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941. xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941. xml"/>
	skipping to change at line 12775 ¶		skipping to change at line 12843 ¶
	(<xref target="trailers.limitations"/>).		(<xref target="trailers.limitations"/>).
	</t>		</t>
	<t>		<t>
	The priority of the absolute form of the request URI over the Host		The priority of the absolute form of the request URI over the Host
	header field by origin servers has been made explicit to align with proxy han dling		header field by origin servers has been made explicit to align with proxy han dling
	(<xref target="field.host"/>).		(<xref target="field.host"/>).
	</t>		</t>
	<t>		<t>
	The grammar definition for the Via field's "received-by" was		The grammar definition for the Via field's "received-by" was
	expanded in RFC 7230 due to changes in the URI grammar for host		expanded in RFC 7230 due to changes in the URI grammar for host
	<xref target="RFC3986"/> that are not desirable for Via. For simplicity,		<xref target="URI"/> that are not desirable for Via. For simplicity,
	we have removed uri-host from the received-by production because it can		we have removed uri-host from the received-by production because it can
	be encompassed by the existing grammar for pseudonym. In particular, this		be encompassed by the existing grammar for pseudonym. In particular, this
	change removed comma from the allowed set of characters for a host name in		change removed comma from the allowed set of characters for a host name in
	received-by		received-by
	(<xref target="field.via"/>).		(<xref target="field.via"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="changes.from.rfc.7231" title="Changes from RFC 7231">		<section anchor="changes.from.rfc.7231" title="Changes from RFC 7231">
	<!-- [rfced] Appendix B.3. Would Section 4.1 (URI References) be a		<!-- [rfced] Appendix B.3. Would Section 4.1 (URI References) be a
	better cross reference for the following?		better cross reference for the following?
	skipping to change at line 12810 ¶		skipping to change at line 12878 ¶
	</t>		</t>
	<t>		<t>
	Parameters in media type, media range, and expectation can be empty via		Parameters in media type, media range, and expectation can be empty via
	one or more trailing semicolons		one or more trailing semicolons
	(<xref target="parameter"/>).		(<xref target="parameter"/>).
	</t>		</t>
	<t>		<t>
	An abstract data type for HTTP messages has been introduced to define the		An abstract data type for HTTP messages has been introduced to define the
	components of a message and their semantics as an abstraction across		components of a message and their semantics as an abstraction across
	multiple HTTP versions, rather than in terms of the specific syntax form of		multiple HTTP versions, rather than in terms of the specific syntax form of
	HTTP/1.1 in <xref target="RFC9112"/>, and reflect the contents after the		HTTP/1.1 in <xref target="HTTP11"/>, and reflect the contents after the
	message is parsed. This makes it easier to distinguish between requirements		message is parsed. This makes it easier to distinguish between requirements
	on the content (what is conveyed) versus requirements on the messaging		on the content (what is conveyed) versus requirements on the messaging
	syntax (how it is conveyed) and avoids baking limitations of early protocol		syntax (how it is conveyed) and avoids baking limitations of early protocol
	versions into the future of HTTP (<xref target="message.abstraction"/>).		versions into the future of HTTP (<xref target="message.abstraction"/>).
	</t>		</t>
	<t>		<t>
	The terms "payload" and "payload body" have been replaced with "content", to better		The terms "payload" and "payload body" have been replaced with "content", to better
	align with its usage elsewhere (e.g., in field names) and to avoid confusion		align with its usage elsewhere (e.g., in field names) and to avoid confusion
	with frame payloads in HTTP/2 and HTTP/3		with frame payloads in HTTP/2 and HTTP/3
	(<xref target="content"/>).		(<xref target="content"/>).
	skipping to change at line 12893 ¶		skipping to change at line 12961 ¶
	The process of creating a redirected request has been clarified		The process of creating a redirected request has been clarified
	(<xref target="status.3xx"/>).		(<xref target="status.3xx"/>).
	</t>		</t>
	<t>		<t>
	Status code 308 (previously defined in <xref target="RFC7538"/>)		Status code 308 (previously defined in <xref target="RFC7538"/>)
	has been added so that it's defined closer to status codes 301, 302, and 307		has been added so that it's defined closer to status codes 301, 302, and 307
	(<xref target="status.308"/>).		(<xref target="status.308"/>).
	</t>		</t>
	<t>		<t>
	Status code 421 (previously defined in		Status code 421 (previously defined in
	<xref target="RFC7540" section="9.1.2"/>) has been added because of its gener al		<xref target="HTTP2" section="9.1.2"/>) has been added because of its general
	applicability. 421 is no longer defined as heuristically cacheable since		applicability. 421 is no longer defined as heuristically cacheable since
	the response is specific to the connection (not the target resource)		the response is specific to the connection (not the target resource)
	(<xref target="status.421"/>).		(<xref target="status.421"/>).
	</t>		</t>
	<t>		<t>
	Status code 422 (previously defined in		Status code 422 (previously defined in
	<xref target="RFC4918" section="11.2"/>) has been added because of its genera l		<xref target="WEBDAV" section="11.2"/>) has been added because of its general
	applicability		applicability
	(<xref target="status.422"/>).		(<xref target="status.422"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="changes.from.rfc.7232" title="Changes from RFC 7232">		<section anchor="changes.from.rfc.7232" title="Changes from RFC 7232">
	<t>		<t>
	Previous revisions of HTTP imposed an arbitrary 60-second limit on the		Previous revisions of HTTP imposed an arbitrary 60-second limit on the
	determination of whether Last-Modified was a strong validator to guard		determination of whether Last-Modified was a strong validator to guard
	against the possibility that the Date and Last-Modified values are		against the possibility that the Date and Last-Modified values are
	generated from different clocks or at somewhat different times during the		generated from different clocks or at somewhat different times during the
	skipping to change at line 13015 ¶		skipping to change at line 13083 ¶
	<contact fullname="Ari Luotonen"/>, <contact fullname="Larry Masinter"/>, <co ntact fullname="Rob McCool"/>,		<contact fullname="Ari Luotonen"/>, <contact fullname="Larry Masinter"/>, <co ntact fullname="Rob McCool"/>,
	<contact fullname="Jeffrey C. Mogul"/>, <contact fullname="Lou Montulli"/>,		<contact fullname="Jeffrey C. Mogul"/>, <contact fullname="Lou Montulli"/>,
	<contact fullname="David Morris"/>, <contact fullname="Henrik Frystyk Nielsen "/>, <contact fullname="Dave Raggett"/>, <contact fullname="Eric Rescorla"/>,		<contact fullname="David Morris"/>, <contact fullname="Henrik Frystyk Nielsen "/>, <contact fullname="Dave Raggett"/>, <contact fullname="Eric Rescorla"/>,
	<contact fullname="Tony Sanders"/>, <contact fullname="Lawrence C. Stewart"/> ,		<contact fullname="Tony Sanders"/>, <contact fullname="Lawrence C. Stewart"/> ,
	<contact fullname="Marc VanHeyningen"/>, and <contact fullname="Steve Zilles" />.		<contact fullname="Marc VanHeyningen"/>, and <contact fullname="Steve Zilles" />.
	</t>		</t>
	<t>		<t>
	This document builds on the many contributions		This document builds on the many contributions
	that went into past specifications of HTTP, including		that went into past specifications of HTTP, including
	<xref target="RFC1945" format="default">RFC 1945</xref>,		<xref target="HTTP10" format="default">RFC 1945</xref>,
	<xref target="RFC2068" format="default">RFC 2068</xref>,		<xref target="RFC2068" format="default">RFC 2068</xref>,
	<xref target="RFC2145" format="default">RFC 2145</xref>,		<xref target="RFC2145" format="default">RFC 2145</xref>,
	<xref target="RFC2616" format="default">RFC 2616</xref>,		<xref target="RFC2616" format="default">RFC 2616</xref>,
	<xref target="RFC2617" format="default">RFC 2617</xref>,		<xref target="RFC2617" format="default">RFC 2617</xref>,
	<xref target="RFC2818" format="default">RFC 2818</xref>,		<xref target="RFC2818" format="default">RFC 2818</xref>,
	<xref target="RFC7230" format="default">RFC 7230</xref>,		<xref target="RFC7230" format="default">RFC 7230</xref>,
	<xref target="RFC7231" format="default">RFC 7231</xref>,		<xref target="RFC7231" format="default">RFC 7231</xref>,
	<xref target="RFC7232" format="default">RFC 7232</xref>,		<xref target="RFC7232" format="default">RFC 7232</xref>,
	<xref target="RFC7233" format="default">RFC 7233</xref>,		<xref target="RFC7233" format="default">RFC 7233</xref>,
	<xref target="RFC7234" format="default">RFC 7234</xref>, and		<xref target="RFC7234" format="default">RFC 7234</xref>, and
End of changes. 123 change blocks.
	225 lines changed or deleted		315 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/