rfc9110v21.xml		rfc9110.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- [CS] updated by Chris 10/01/21 -->
	<!-- draft submitted in xml v3 -->
	<!-- [auth]
	This XML document is the output of clean-for-DTD.xslt; a tool that strips
	extensions to RFC 7749 from documents for processing with xml2rfc.
	<!-- [auth] TARGET-GENERATOR: 202007-->
	<!-- [auth] TARGET-VOCABULARY: 3-->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc version="3"		<rfc version="3"
	tocDepth="4"		tocDepth="4"
	tocInclude="true"		tocInclude="true"
	skipping to change at line 37 ¶		skipping to change at line 26 ¶
	category="std"		category="std"
	consensus="true"		consensus="true"
	xmlns:xi="http://www.w3.org/2001/XInclude"		xmlns:xi="http://www.w3.org/2001/XInclude"
	xml:lang="en"		xml:lang="en"
	ipr="pre5378Trust200902"		ipr="pre5378Trust200902"
	obsoletes="2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694"		obsoletes="2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694"
	updates="3864"		updates="3864"
	docName="draft-ietf-httpbis-semantics-19"		docName="draft-ietf-httpbis-semantics-19"
	number="9110">		number="9110">
	<!-- [auth] see https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/420-->
	<!-- FYI The authors added these silencers due to issue #420.
	I have commented them out and everything seems to be working.
	<!--
	<?v3xml2rfc silence="Warning: Setting consensus="true" for IETF STD document"?>
	<?v3xml2rfc silence="Warning: Expected a valid submissionType (stream) setting"?>
	<front>		<front>
	<title>HTTP Semantics</title>		<title>HTTP Semantics</title>
	<seriesInfo name="RFC" value="9110"/>		<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="STD" value="97"/>		<seriesInfo name="STD" value="97"/>
	<author fullname="Roy T. Fielding"		<author fullname="Roy T. Fielding"
	initials="R."		initials="R."
	surname="Fielding"		surname="Fielding"
	role="editor">		role="editor">
	<organization>Adobe</organization>		<organization>Adobe</organization>
	skipping to change at line 1035 ¶		skipping to change at line 1016 ¶
	IANA maintains the registry of URI Schemes <xref target="BCP35"/> at		IANA maintains the registry of URI Schemes <xref target="BCP35"/> at
	<eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle"/>.		<eref target="https://www.iana.org/assignments/uri-schemes/" brackets="angle"/>.
	Although requests might target any URI scheme, the following schemes are		Although requests might target any URI scheme, the following schemes are
	inherent to HTTP servers:		inherent to HTTP servers:
	</t>		</t>
	<table align="left" anchor="uri.scheme.table">		<table align="left" anchor="uri.scheme.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>URI Scheme</th>		<th>URI Scheme</th>
	<th>Description</th>		<th>Description</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>http</td>		<td>http</td>
	<td>Hypertext Transfer Protocol</td>		<td>Hypertext Transfer Protocol</td>
	<td>		<td>
	<xref target="http.uri" format="counter"/>		<xref target="http.uri" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	skipping to change at line 1181 ¶		skipping to change at line 1162 ¶
	<li>The scheme and host are case-insensitive and normally provided in		<li>The scheme and host are case-insensitive and normally provided in
	lowercase; all other components are compared in a case-sensitive		lowercase; all other components are compared in a case-sensitive
	manner.</li>		manner.</li>
	<li>Characters other than those in the "reserved" set are equivalent to		<li>Characters other than those in the "reserved" set are equivalent 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="URI" sectionFormat="bare" section="2.1"/> and <xref target="URI" sectionFormat="bare" section="2.2"/> of <xref target="URI"/>).</li>		Sections <xref target="URI" sectionFormat="bare" section="2.1"/> and <xref target="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><![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>MAY</bcp14>		can be assumed to identify the same resource, and any HTTP component <bcp14>MAY</bcp14>
	perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp14> be		perform normalization. As a result, distinct resources <bcp14>SHOULD NOT</bcp14> 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="URI" section="6.2"/>).		method defined in <xref target="URI" section="6.2"/>).
	skipping to change at line 1269 ¶		skipping to change at line 1250 ¶
	</t>		</t>
	<section anchor="origin" title="URI Origin">		<section anchor="origin" title="URI Origin">
	<iref primary="true" item="origin"/>		<iref primary="true" item="origin"/>
	<iref primary="true" item="URI" subitem="origin"/>		<iref primary="true" item="URI" subitem="origin"/>
	<t>		<t>
	The "origin" for a given URI is the triple of scheme, host,		The "origin" for a given URI is the triple of scheme, host,
	and port after normalizing the scheme and host to lowercase and		and port after normalizing the scheme and host to lowercase and
	normalizing the port to remove any leading zeros. If port is elided from		normalizing the port to remove any leading zeros. If port is elided from
	the URI, the default port for that scheme is used. For example, the URI		the URI, the default port for that scheme is used. For example, the URI
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	https://Example.Com/happy.js		https://Example.Com/happy.js
	]]></artwork>		]]></artwork>
	<t>		<t>
	would have the origin		would have the origin
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	{ "https", "example.com", "443" }		{ "https", "example.com", "443" }
	]]></artwork>		]]></artwork>
	<t>		<t>
	which can also be described as the normalized URI prefix with port always		which can also be described as the normalized URI prefix with port always
	present:		present:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	https://example.com:443		https://example.com:443
	]]></artwork>		]]></artwork>
	<t>		<t>
	Each origin defines its own namespace and controls how identifiers		Each origin defines its own namespace and controls how identifiers
	within that namespace are mapped to resources. In turn, how the origin		within that namespace are mapped to resources. In turn, how the origin
	responds to valid requests, consistently over time, determines the		responds to valid requests, consistently over time, determines the
	semantics that users will associate with a URI, and the usefulness of		semantics that users will associate with a URI, and the usefulness of
	those semantics is what ultimately transforms these mechanisms into a		those semantics is what ultimately transforms these mechanisms into a
	resource for users to reference and access in the future.		resource for users to reference and access in the future.
	</t>		</t>
	skipping to change at line 1764 ¶		skipping to change at line 1745 ¶
	at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single		at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
	comma (",") and optional whitespace (<xref target="whitespace" format="none">OWS</xref> ,		comma (",") and optional whitespace (<xref target="whitespace" format="none">OWS</xref> ,
	defined in <xref target="whitespace"/>).		defined in <xref target="whitespace"/>).
	</t>		</t>
	<section anchor="abnf.extension.sender" title="Sender Requirements">		<section anchor="abnf.extension.sender" title="Sender Requirements">
	<t>		<t>
	In any production that uses the list construct, a sender <bcp14>MUST NOT</bcp14>		In any production that uses the list construct, a sender <bcp14>MUST NOT</bcp14>
	generate empty list elements. In other words, a sender has to generate		generate empty list elements. In other words, a sender has to generate
	lists that satisfy the following syntax:		lists that satisfy the following syntax:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	1#element => element *( OWS "," OWS element )		1#element => element *( OWS "," OWS element )
	]]></artwork>		]]></artwork>
	<t>		<t>
	and:		and:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	#element => [ 1#element ]		#element => [ 1#element ]
	]]></artwork>		]]></artwork>
	<t>		<t>
	and for n &gt;= 1 and m &gt; 1:		and for n &gt;= 1 and m &gt; 1:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )		<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
	]]></artwork>		]]></artwork>
	<t>		<t>
	<xref target="collected.abnf"/> shows the collected ABNF for senders		<xref target="collected.abnf"/> shows the collected ABNF for senders
	after the list constructs have been expanded.		after the list constructs have been expanded.
	</t>		</t>
	</section>		</section>
	<section anchor="abnf.extension.recipient" title="Recipient Requirements">		<section anchor="abnf.extension.recipient" title="Recipient Requirements">
	<t>		<t>
	Empty elements do not contribute to the count of elements present.		Empty elements do not contribute to the count of elements present.
	A recipient <bcp14>MUST</bcp14> parse and ignore		A recipient <bcp14>MUST</bcp14> parse and ignore
	a reasonable number of empty list elements: enough to handle common mistakes		a reasonable number of empty list elements: enough to handle common mistakes
	by senders that merge values, but not so much that they could be used as a		by senders that merge values, but not so much that they could be used as a
	denial-of-service mechanism. In other words, a recipient <bcp14>MUST</bcp14> accept lis ts		denial-of-service mechanism. In other words, a recipient <bcp14>MUST</bcp14> accept lis ts
	that satisfy the following syntax:		that satisfy the following syntax:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	#element => [ element ] *( OWS "," OWS [ element ] )		#element => [ element ] *( OWS "," OWS [ element ] )
	]]></artwork>		]]></artwork>
	<t>		<t>
	Note that because of the potential presence of empty list elements, the		Note that because of the potential presence of empty list elements, the
	RFC 5234 ABNF cannot enforce the cardinality of list elements, and		RFC 5234 ABNF cannot enforce the cardinality of list elements, and
	consequently all cases are mapped as if there was no cardinality specified.		consequently all cases are mapped as if there was no cardinality specified.
	</t>		</t>
	<t>		<t>
	For example, given these ABNF productions:		For example, given these ABNF productions:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	example-list = 1#example-list-elmt		example-list = 1#example-list-elmt
	example-list-elmt = token ; see Section 5.6.2		example-list-elmt = token ; see Section 5.6.2
	]]></artwork>		]]></artwork>
	<t>		<t>
	Then the following are valid values for example-list (not including the		Then the following are valid values for example-list (not including the
	double quotes, which are present for delimitation only):		double quotes, which are present for delimitation only):
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	"foo,bar"		"foo,bar"
	"foo ,bar,"		"foo ,bar,"
	"foo , ,bar,charlie"		"foo , ,bar,charlie"
	]]></artwork>		]]></artwork>
	<t>		<t>
	In contrast, the following values would be invalid, since at least one		In contrast, the following values would be invalid, since at least one
	non-empty element is required by the example-list production:		non-empty element is required by the example-list production:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	""		""
	","		","
	", ,"		", ,"
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="tokens" title="Tokens">		<section anchor="tokens" title="Tokens">
	<t anchor="rule.token.separators">		<t anchor="rule.token.separators">
	Tokens are short textual identifiers that do not include whitespace or		Tokens are short textual identifiers that do not include whitespace or
	skipping to change at line 1989 ¶		skipping to change at line 1970 ¶
	three are defined here. The preferred format is a fixed-length and		three are defined here. The preferred format is a fixed-length and
	single-zone subset of the date and time specification used by the		single-zone subset of the date and time specification used by the
	Internet Message Format <xref target="RFC5322"/>.		Internet Message Format <xref target="RFC5322"/>.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="HTTP-date"/>		<iref primary="true" item="Grammar" subitem="HTTP-date"/>
	<sourcecode type="abnf9110"><![CDATA[ HTTP-date = IMF-fixdate / obs-dat e		<sourcecode type="abnf9110"><![CDATA[ HTTP-date = IMF-fixdate / obs-dat e
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	An example of the preferred format is		An example of the preferred format is
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate		Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
	]]></artwork>		]]></artwork>
	<t>		<t>
	Examples of the two obsolete formats are		Examples of the two obsolete formats are
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format		Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
	Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format		Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
	]]></artwork>		]]></artwork>
	<t>		<t>
	A recipient that parses a timestamp value in an HTTP field <bcp14>MUST</bcp14>		A recipient that parses a timestamp value in an HTTP field <bcp14>MUST</bcp14>
	accept all three HTTP-date formats. When a sender generates a field		accept all three HTTP-date formats. When a sender generates a field
	that contains one or more timestamps defined as HTTP-date,		that contains one or more timestamps defined as HTTP-date,
	the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate format.		the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate format.
	</t>		</t>
	<t>		<t>
	skipping to change at line 3269 ¶		skipping to change at line 3250 ¶
	either provided as the content of the message or		either provided as the content of the message or
	referred to by the message semantics and the target		referred to by the message semantics and the target
	URI. The representation data is in a format and encoding defined by		URI. The representation data is in a format and encoding defined by
	the representation metadata header fields.		the representation metadata header fields.
	</t>		</t>
	<t>		<t>
	The data type of the representation data is determined via the header fields		The data type of the representation data is determined via the header fields
	<xref target="field.content-type" format="none">Content-Type</xref> and <xref target="f ield.content-encoding" format="none">Content-Encoding</xref>.		<xref target="field.content-type" format="none">Content-Type</xref> and <xref target="f ield.content-encoding" format="none">Content-Encoding</xref>.
	These define a two-layer, ordered encoding model:		These define a two-layer, ordered encoding model:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	representation-data := Content-Encoding( Content-Type( data ) )		representation-data := Content-Encoding( Content-Type( data ) )
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="representation.metadata" title="Representation Metadata">		<section anchor="representation.metadata" title="Representation Metadata">
	<t>		<t>
	Representation header fields provide metadata about the representation.		Representation header fields provide metadata about the representation.
	When a message includes content, the representation header fields		When a message includes content, the representation header fields
	describe how to interpret that data. In a response to a HEAD request, the		describe how to interpret that data. In a response to a HEAD request, the
	representation header fields describe the representation data that would		representation header fields describe the representation data that would
	have been enclosed in the content if the same request had been a GET.		have been enclosed in the content if the same request had been a GET.
	skipping to change at line 3370 ¶		skipping to change at line 3351 ¶
	type registry.		type registry.
	Parameter values might or might not be case-sensitive, depending on the		Parameter values might or might not be case-sensitive, depending on the
	semantics of the parameter name.		semantics of the parameter name.
	</t>		</t>
	<t>		<t>
	For example, the following media types are equivalent in describing HTML		For example, the following media types are equivalent in describing HTML
	text data encoded in the UTF-8 character encoding scheme, but the first is		text data encoded in the UTF-8 character encoding scheme, but the first is
	preferred for consistency (the "charset" parameter value is defined as		preferred for consistency (the "charset" parameter value is defined as
	being case-insensitive in <xref target="RFC2046" sectionFormat="comma" section="4.1.2"/ >):		being case-insensitive in <xref target="RFC2046" sectionFormat="comma" section="4.1.2"/ >):
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	text/html;charset=utf-8		text/html;charset=utf-8
	Text/HTML;Charset="utf-8"		Text/HTML;Charset="utf-8"
	text/html; charset="utf-8"		text/html; charset="utf-8"
	text/html;charset=UTF-8		text/html;charset=UTF-8
	]]></artwork>		]]></artwork>
	<t>		<t>
	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 <xref target="BCP13"/>.		procedures defined in <xref target="BCP13"/>.
	</t>		</t>
	</section>		</section>
	skipping to change at line 3624 ¶		skipping to change at line 3605 ¶
	<t>		<t>
	A language tag is a sequence of one or more case-insensitive subtags, each		A language tag is a sequence of one or more case-insensitive subtags, each
	separated by a hyphen character ("-", %x2D). In most cases, a language tag		separated by a hyphen character ("-", %x2D). In most cases, a language tag
	consists of a primary language subtag that identifies a broad family of		consists of a primary language subtag that identifies a broad family of
	related languages (e.g., "en" = English), which is optionally followed by a		related languages (e.g., "en" = English), which is optionally followed by a
	series of subtags that refine or narrow that language's range (e.g.,		series of subtags that refine or narrow that language's range (e.g.,
	"en-CA" = the variety of English as communicated in Canada).		"en-CA" = the variety of English as communicated in Canada).
	Whitespace is not allowed within a language tag.		Whitespace is not allowed within a language tag.
	Example tags include:		Example tags include:
	</t>		</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN		fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
	]]></artwork>		]]></artwork>
	<t>		<t>
	See <xref target="RFC5646"/> for further information.		See <xref target="RFC5646"/> for further information.
	</t>		</t>
	</section>		</section>
	</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"/>
	skipping to change at line 4335 ¶		skipping to change at line 4316 ¶
	</t>		</t>
	<t>		<t>
	This specification defines a number of standardized methods that are		This specification defines a number of standardized methods that are
	commonly used in HTTP, as outlined by the following table.		commonly used in HTTP, as outlined by the following table.
	</t>		</t>
	<table align="left" anchor="table.of.methods">		<table align="left" anchor="table.of.methods">
	<thead>		<thead>
	<tr>		<tr>
	<th>Method Name</th>		<th>Method Name</th>
	<th>Description</th>		<th>Description</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>GET</td>		<td>GET</td>
	<td>Transfer a current representation of the target resource.</td>		<td>Transfer a current representation of the target resource.</td>
	<td>		<td>
	<xref target="GET" format="counter"/>		<xref target="GET" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	skipping to change at line 5749 ¶		skipping to change at line 5730 ¶
	<xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field containing at least one		<xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field containing at least one
	challenge applicable to the proxy for the requested resource.		challenge applicable to the proxy for the requested resource.
	</t>		</t>
	<iref primary="true" item="Grammar" subitem="challenge"/>		<iref primary="true" item="Grammar" subitem="challenge"/>
	<sourcecode type="abnf9110"><![CDATA[ challenge = auth-scheme [ 1*SP ( toke n68 / #auth-param ) ]		<sourcecode type="abnf9110"><![CDATA[ challenge = auth-scheme [ 1*SP ( toke n68 / #auth-param ) ]
	]]></sourcecode>		]]></sourcecode>
	<aside>		<aside>
	<t>		<t>
	<strong>Note:</strong> Many clients fail to parse a challenge that conta ins an unknown		<strong>Note:</strong> Many clients fail to parse a challenge that conta ins an unknown
	scheme. A workaround for this problem is to list well-supported schemes		scheme. A workaround for this problem is to list well-supported schemes
	(such as "basic") first.<!-- [auth] see https://greenbytes.de/tech/tc/httpauth/#multi basicunknown2 -->		(such as "basic") first.
	</t>		</t>
	</aside>		</aside>
	<t>		<t>
	A user agent that wishes to authenticate itself with an origin server		A user agent that wishes to authenticate itself with an origin server
	-- usually, but not necessarily, after receiving a		-- usually, but not necessarily, after receiving a
	<xref target="status.401" format="none">401 (Unauthorized)</xref> -- can do so by inclu ding an		<xref target="status.401" format="none">401 (Unauthorized)</xref> -- can do so by inclu ding an
	<xref target="field.authorization" format="none">Authorization</xref> header field with the request.		<xref target="field.authorization" format="none">Authorization</xref> header field with the request.
	</t>		</t>
	<t>		<t>
	A client that wishes to authenticate itself with a proxy -- usually,		A client that wishes to authenticate itself with a proxy -- usually,
	skipping to change at line 7619 ¶		skipping to change at line 7600 ¶
	If the representation data has a content coding applied, each byte range is		If the representation data has a content coding applied, each byte range is
	calculated with respect to the encoded sequence of bytes, not the sequence		calculated with respect to the encoded sequence of bytes, not the sequence
	of underlying bytes that would be obtained after decoding.		of underlying bytes that would be obtained after decoding.
	</t>		</t>
	<t>		<t>
	Examples of bytes range specifiers:		Examples of bytes range specifiers:
	</t>		</t>
	<ul>		<ul>
	<li>		<li>
	<t>The first 500 bytes (byte offsets 0-499, inclusive):</t>		<t>The first 500 bytes (byte offsets 0-499, inclusive):</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=0-499		bytes=0-499
	]]></artwork>		]]></artwork>
	</li>		</li>
	<li>		<li>
	<t>The second 500 bytes (byte offsets 500-999, inclusive):</t>		<t>The second 500 bytes (byte offsets 500-999, inclusive):</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=500-999		bytes=500-999
	]]></artwork>		]]></artwork>
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	A client can limit the number of bytes requested without knowing the size		A client can limit the number of bytes requested without knowing the size
	of the <xref target="selected.representation" format="none">selected representation</xr ef>.		of the <xref target="selected.representation" format="none">selected representation</xr ef>.
	If the <xref target="rule.int-range" format="none">last-pos</xref> value is absent, or if the value is		If the <xref target="rule.int-range" format="none">last-pos</xref> value is absent, or if the value is
	greater than or equal to the current length of the representation data, the		greater than or equal to the current length of the representation data, the
	byte range is interpreted as the remainder of the representation (i.e., the		byte range is interpreted as the remainder of the representation (i.e., the
	skipping to change at line 7651 ¶		skipping to change at line 7632 ¶
	representation using a <xref target="rule.suffix-range" format="none">suffix-range</xre f>.		representation using a <xref target="rule.suffix-range" format="none">suffix-range</xre f>.
	If the selected representation is shorter than the specified		If the selected representation is shorter than the specified
	<xref target="rule.suffix-range" format="none">suffix-length</xref>, the entire represe ntation is used.		<xref target="rule.suffix-range" format="none">suffix-length</xref>, the entire represe ntation is used.
	</t>		</t>
	<t>		<t>
	Additional examples, assuming a representation of length 10000:		Additional examples, assuming a representation of length 10000:
	</t>		</t>
	<ul>		<ul>
	<li>		<li>
	<t>The final 500 bytes (byte offsets 9500-9999, inclusive):</t>		<t>The final 500 bytes (byte offsets 9500-9999, inclusive):</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=-500		bytes=-500
	]]></artwork>		]]></artwork>
	<t>Or:</t>		<t>Or:</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=9500-		bytes=9500-
	]]></artwork>		]]></artwork>
	</li>		</li>
	<li>		<li>
	<t>The first and last bytes only (bytes 0 and 9999):</t>		<t>The first and last bytes only (bytes 0 and 9999):</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=0-0,-1		bytes=0-0,-1
	]]></artwork>		]]></artwork>
	</li>		</li>
	<li>		<li>
	<t>The first, middle, and last 1000 bytes:</t>		<t>The first, middle, and last 1000 bytes:</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes= 0-999, 4500-5499, -1000		bytes= 0-999, 4500-5499, -1000
	]]></artwork>		]]></artwork>
	</li>		</li>
	<li>		<li>
	<t>Other valid (but not canonical) specifications of the second 500		<t>Other valid (but not canonical) specifications of the second 500
	bytes (byte offsets 500-999, inclusive):</t>		bytes (byte offsets 500-999, inclusive):</t>
	<artwork type="example"><![CDATA[		<artwork><![CDATA[
	bytes=500-600,601-999		bytes=500-600,601-999
	bytes=500-700,601-999		bytes=500-700,601-999
	]]></artwork>		]]></artwork>
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	For a <xref target="GET" format="none">GET</xref> request, a valid bytes <xref target=" rule.ranges-specifier" format="none">range-spec</xref>		For a <xref target="GET" format="none">GET</xref> request, a valid bytes <xref target=" rule.ranges-specifier" format="none">range-spec</xref>
	is <xref target="satisfiable" format="none">satisfiable</xref> if it is either:		is <xref target="satisfiable" format="none">satisfiable</xref> if it is either:
	</t>		</t>
	<ul>		<ul>
	skipping to change at line 10733 ¶		skipping to change at line 10714 ¶
	</t>		</t>
	</section>		</section>
	<section anchor="method.registration" title="Method Registration">		<section anchor="method.registration" title="Method Registration">
	<t>		<t>
	IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at		IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at
	<eref target="https://www.iana.org/assignments/http-methods" brackets="angle"/> with the		<eref target="https://www.iana.org/assignments/http-methods" brackets="angle"/> with the
	registration procedure of <xref target="method.registry"/> and the method		registration procedure of <xref target="method.registry"/> and the method
	names summarized in the following table.		names summarized in the following table.
	</t>		</t>
	<!-- [auth] AUTOGENERATED FROM extract-method-defs.xslt, do not edit manually- ->
	<table anchor="iana.method.registration.table">		<table anchor="iana.method.registration.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>Method</th>		<th>Method</th>
	<th>Safe</th>		<th>Safe</th>
	<th>Idempotent</th>		<th>Idempotent</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>CONNECT</td>		<td>CONNECT</td>
	<td>no</td>		<td>no</td>
	<td>no</td>		<td>no</td>
	<td>		<td>
	<xref target="CONNECT" format="counter"/>		<xref target="CONNECT" format="counter"/>
	</td>		</td>
	skipping to change at line 10818 ¶		skipping to change at line 10798 ¶
	<tr>		<tr>
	<td>*</td>		<td>*</td>
	<td>no</td>		<td>no</td>
	<td>no</td>		<td>no</td>
	<td>		<td>
	<xref target="method.registration" format="counter"/>		<xref target="method.registration" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<!--[auth] (END)-->
	<t>		<t>
	<iref primary="true" item="Method" subitem="*"/>		<iref primary="true" item="Method" subitem="*"/>
	The method name "*" is reserved because using "*" as a method name would		The method name "*" is reserved because using "*" as a method name would
	conflict with its usage as a wildcard in some fields (e.g.,		conflict with its usage as a wildcard in some fields (e.g.,
	"Access-Control-Request-Method").		"Access-Control-Request-Method").
	</t>		</t>
	</section>		</section>
	<section anchor="status.code.registration" title="Status Code Registration">		<section anchor="status.code.registration" title="Status Code Registration">
	<t>		<t>
	IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry"		IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry"
	at <eref target="https://www.iana.org/assignments/http-status-codes"		at <eref target="https://www.iana.org/assignments/http-status-codes"
	brackets="angle"/> with		brackets="angle"/> with
	the registration procedure of <xref target="status.code.registry"/> and the		the registration procedure of <xref target="status.code.registry"/> and the
	status code values summarized in the following table.		status code values summarized in the following table.
	</t>		</t>
	<!-- [auth] AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manu ally-->
	<table anchor="iana.status.code.registration.table">		<table anchor="iana.status.code.registration.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>Value</th>		<th>Value</th>
	<th>Description</th>		<th>Description</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>100</td>		<td>100</td>
	<td>Continue</td>		<td>Continue</td>
	<td>		<td>
	<xref target="status.100" format="counter"/>		<xref target="status.100" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	skipping to change at line 11169 ¶		skipping to change at line 11147 ¶
	</tr>		</tr>
	<tr>		<tr>
	<td>505</td>		<td>505</td>
	<td>HTTP Version Not Supported</td>		<td>HTTP Version Not Supported</td>
	<td>		<td>
	<xref target="status.505" format="counter"/>		<xref target="status.505" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<!--[auth] (END)-->
	</section>		</section>
	<section anchor="field.name.registration" title="Field Name Registration">		<section anchor="field.name.registration" title="Field Name Registration">
	<t>		<t>
	This specification updates the HTTP-related aspects of the existing		This specification updates the HTTP-related aspects of the existing
	registration procedures for message header fields defined in <xref target="RFC3864"/>.		registration procedures for message header fields defined in <xref target="RFC3864"/>.
	It replaces the old procedures as they relate to HTTP by defining a new		It replaces the old procedures as they relate to HTTP by defining a new
	registration procedure and moving HTTP field definitions into a separate		registration procedure and moving HTTP field definitions into a separate
	registry.		registry.
	</t>		</t>
	<t>		<t>
	skipping to change at line 11220 ¶		skipping to change at line 11197 ¶
	<t>		<t>
	HTTP field name registrations have been moved to		HTTP field name registrations have been moved to
	[<eref target="https://www.iana.org/assignments/http-fields" brackets="none"/>] per		[<eref target="https://www.iana.org/assignments/http-fields" brackets="none"/>] per
	[RFC9110].		[RFC9110].
	</t>		</t>
	</aside>		</aside>
	<t>		<t>
	IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry"		IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
	with the field names listed in the following table.		with the field names listed in the following table.
	</t>		</t>
	<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
	<table align="left" anchor="iana.header.registration.table">		<table align="left" anchor="iana.header.registration.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>Field Name</th>		<th>Field Name</th>
	<th>Status</th>		<th>Status</th>
	<th>Ref.</th>		<th>Reference</th>
	<th>Comments</th>		<th>Comments</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>Accept</td>		<td>Accept</td>
	<td>permanent</td>		<td>permanent</td>
	<td>		<td>
	<xref target="field.accept" format="counter"/>		<xref target="field.accept" format="counter"/>
	</td>		</td>
	skipping to change at line 11577 ¶		skipping to change at line 11553 ¶
	<tr>		<tr>
	<td>*</td>		<td>*</td>
	<td>permanent</td>		<td>permanent</td>
	<td>		<td>
	<xref target="field.vary" format="counter"/>		<xref target="field.vary" format="counter"/>
	</td>		</td>
	<td>(reserved)</td>		<td>(reserved)</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<!--(END)-->
	<t anchor="field.asterisk">		<t anchor="field.asterisk">
	<iref primary="true" item="Fields" subitem="*"/>		<iref primary="true" item="Fields" subitem="*"/>
	The field name "*" is reserved because using that name as		The field name "*" is reserved because using that name as
	an HTTP header field might conflict with its special semantics in the		an HTTP header field might conflict with its special semantics in the
	<xref target="field.vary" format="none">Vary</xref> header field (<xref target="field.v ary"/>).		<xref target="field.vary" format="none">Vary</xref> header field (<xref target="field.v ary"/>).
	</t>		</t>
	<t>		<t>
	<iref primary="true" item="Fields" subitem="Content-MD5"/>		<iref primary="true" item="Fields" subitem="Content-MD5"/>
	<iref primary="true" item="Header Fields" subitem="Content-MD5"/>		<iref primary="true" item="Header Fields" subitem="Content-MD5"/>
	skipping to change at line 11623 ¶		skipping to change at line 11598 ¶
	<eref target="https://www.iana.org/assignments/http-parameters/"		<eref target="https://www.iana.org/assignments/http-parameters/"
	brackets="angle"/>		brackets="angle"/>
	with the registration procedure of <xref target="content.coding.registry"/>		with the registration procedure of <xref target="content.coding.registry"/>
	and the content coding names summarized in the table below.		and the content coding names summarized in the table below.
	</t>		</t>
	<table align="left" anchor="iana.content.coding.registration.table">		<table align="left" anchor="iana.content.coding.registration.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>Name</th>		<th>Name</th>
	<th>Description</th>		<th>Description</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>compress</td>		<td>compress</td>
	<td>UNIX "compress" data format <xref target="Welch"/>		<td>UNIX "compress" data format <xref target="Welch"/>
	</td>		</td>
	<td>		<td>
	<xref target="compress.coding" format="counter"/>		<xref target="compress.coding" format="counter"/>
	</td>		</td>
	skipping to change at line 11688 ¶		skipping to change at line 11663 ¶
	<eref target="https://www.iana.org/assignments/http-parameters/"		<eref target="https://www.iana.org/assignments/http-parameters/"
	brackets="angle"/>		brackets="angle"/>
	with the registration procedure of <xref target="range.unit.registry"/>		with the registration procedure of <xref target="range.unit.registry"/>
	and the range unit names summarized in the table below.		and the range unit names summarized in the table below.
	</t>		</t>
	<table align="left" anchor="iana.range.units.table">		<table align="left" anchor="iana.range.units.table">
	<thead>		<thead>
	<tr>		<tr>
	<th>Range Unit Name</th>		<th>Range Unit Name</th>
	<th>Description</th>		<th>Description</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>bytes</td>		<td>bytes</td>
	<td>a range of octets</td>		<td>a range of octets</td>
	<td>		<td>
	<xref target="byte.ranges" format="counter"/>		<xref target="byte.ranges" format="counter"/>
	</td>		</td>
	</tr>		</tr>
	skipping to change at line 11750 ¶		skipping to change at line 11725 ¶
	brackets="angle"/>		brackets="angle"/>
	with the registration procedure described in <xref target="upgrade.token.registry"/>		with the registration procedure described in <xref target="upgrade.token.registry"/>
	and the upgrade token names summarized in the following table.		and the upgrade token names summarized in the following table.
	</t>		</t>
	<table align="left">		<table align="left">
	<thead>		<thead>
	<tr>		<tr>
	<th>Name</th>		<th>Name</th>
	<th>Description</th>		<th>Description</th>
	<th>Expected Version Tokens</th>		<th>Expected Version Tokens</th>
	<th>Ref.</th>		<th>Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>HTTP</td>		<td>HTTP</td>
	<td>Hypertext Transfer Protocol</td>		<td>Hypertext Transfer Protocol</td>
	<td>any DIGIT.DIGIT (e.g., "2.0")</td>		<td>any DIGIT.DIGIT (e.g., "2.0")</td>
	<td>		<td>
	<xref target="protocol.version" format="counter"/>		<xref target="protocol.version" format="counter"/>
	</td>		</td>
	skipping to change at line 11777 ¶		skipping to change at line 11752 ¶
	<back>		<back>
	<displayreference target="HTTP10" to="HTTP/1.0"/>		<displayreference target="HTTP10" to="HTTP/1.0"/>
	<displayreference target="HTTP11" to="HTTP/1.1"/>		<displayreference target="HTTP11" to="HTTP/1.1"/>
	<displayreference target="HTTP2" to="HTTP/2"/>		<displayreference target="HTTP2" to="HTTP/2"/>
	<displayreference target="HTTP3" to="HTTP/3"/>		<displayreference target="HTTP3" to="HTTP/3"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<!-- [I-D.ietf-httpbis-cache]; companion document RFC 9111 -->
	<reference anchor='CACHING' target='https://www.rfc-editor.org/info/rfc9111'>		<reference anchor='CACHING' target='https://www.rfc-editor.org/info/rfc9111'>
	<front>		<front>
	<title>HTTP Caching</title>		<title>HTTP Caching</title>
	<author initials='R' surname='Fielding' fullname='Roy T. Fielding' role=' editor'>		<author initials='R' surname='Fielding' fullname='Roy T. Fielding' role=' editor'>
	<organization />		<organization />
	</author>		</author>
	<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role ='editor'>		<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role ='editor'>
	<organization />		<organization />
	</author>		</author>
	<author initials='J' surname='Reschke' fullname='Julian Reschke' role='ed itor'>		<author initials='J' surname='Reschke' fullname='Julian Reschke' role='ed itor'>
	skipping to change at line 11888 ¶		skipping to change at line 11862 ¶
	<refcontent>IEEE Computer 17(6)</refcontent>		<refcontent>IEEE Computer 17(6)</refcontent>
	<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 -->
	<reference anchor="HTTP11" target='https://www.rfc-editor.org/info/rfc9112'>		<reference anchor="HTTP11" target='https://www.rfc-editor.org/info/rfc9112'>
	<front>		<front>
	<title>HTTP/1.1</title>		<title>HTTP/1.1</title>
	<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role ="editor">		<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role ="editor">
	<organization>Adobe</organization>		<organization>Adobe</organization>
	</author>		</author>
	<author initials="M." surname="Nottingham" fullname="Mark Nottingham" ro le="editor">		<author initials="M." surname="Nottingham" fullname="Mark Nottingham" ro le="editor">
	<organization>Fastly</organization>		<organization>Fastly</organization>
	</author>		</author>
	<author initials="J." surname="Reschke" fullname="Julian Reschke" role=" editor">		<author initials="J." surname="Reschke" fullname="Julian Reschke" role=" editor">
	skipping to change at line 12023 ¶		skipping to change at line 11996 ¶
	<date month="May" year="1996"/>		<date month="May" year="1996"/>
	</front>		</front>
	<seriesInfo name="RFC" value="1945"/>		<seriesInfo name="RFC" value="1945"/>
	<seriesInfo name="DOI" value="10.17487/RFC1945"/>		<seriesInfo name="DOI" value="10.17487/RFC1945"/>
	</reference>		</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 -->
	<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/rfc2324">		<reference anchor="RFC2324" target="https://www.rfc-editor.org/info/rfc2324">
	<front>		<front>
	<title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>		<title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>
	<author initials="L." surname="Masinter" fullname="L. Masinter"/>		<author initials="L." surname="Masinter" fullname="L. Masinter"/>
	<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"/>
	skipping to change at line 12101 ¶		skipping to change at line 12073 ¶
	<author initials="P." surname="McManus" fullname="P. McManus"/>		<author initials="P." surname="McManus" fullname="P. McManus"/>
	<author initials="J." surname="Reschke" fullname="J. Reschke"/>		<author initials="J." surname="Reschke" fullname="J. Reschke"/>
	<date year="2016" month="April"/>		<date year="2016" month="April"/>
	</front>		</front>
	<seriesInfo name="RFC" value="7838"/>		<seriesInfo name="RFC" value="7838"/>
	<seriesInfo name="DOI" value="10.17487/RFC7838"/>		<seriesInfo name="DOI" value="10.17487/RFC7838"/>
	</reference>		</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 AUTH48*R state as of 2/10/2022; companion document RFC
	9114 (RFC number updated at request of AD) -->
	<reference anchor='HTTP3' target='https://www.rfc-editor.org/info/rfc9114'>		<reference anchor='HTTP3' target='https://www.rfc-editor.org/info/rfc9114'>
	<front>		<front>
	<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>		<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
	<author initials="M."		<author initials="M."
	surname="Bishop"		surname="Bishop"
	fullname="Mike Bishop"		fullname="Mike Bishop"
	role="editor"/>		role="editor"/>
	<date year="2022" month="April"/>		<date year="2022" month="April"/>
	</front>		</front>
	<seriesInfo name="RFC" value="9114"/>		<seriesInfo name="RFC" value="9114"/>
End of changes. 44 change blocks.
	60 lines changed or deleted		32 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/