rfc9110v3.xml   rfc9110.xml 
skipping to change at line 57 skipping to change at line 57
<title abbrev="HTTP Semantics">HTTP Semantics</title> <title abbrev="HTTP Semantics">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>
<address> <address>
<postal> <postal>
<street>345 Park Ave</street> <postalLine>345 Park Ave</postalLine>
<city>San Jose</city> <postalLine>San Jose, CA 95110</postalLine>
<region>CA</region> <postalLine>United States of America</postalLine>
<code>95110</code>
<country>United States of America</country>
</postal> </postal>
<email>fielding@gbiv.com</email> <email>fielding@gbiv.com</email>
<uri>https://roy.gbiv.com/</uri> <uri>https://roy.gbiv.com/</uri>
</address> </address>
</author> </author>
<author fullname="Mark Nottingham" <author fullname="Mark Nottingham"
initials="M." initials="M."
surname="Nottingham" surname="Nottingham"
role="editor"> role="editor">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<postal> <postal>
<city>Prahran VIC</city> <postalLine>Prahran</postalLine>
<country>Australia</country> <postalLine>Australia</postalLine>
</postal> </postal>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<author fullname="Julian Reschke" <author fullname="Julian Reschke"
initials="J." initials="J."
surname="Reschke" surname="Reschke"
role="editor"> role="editor">
<organization abbrev="greenbytes">greenbytes GmbH</organizati on> <organization abbrev="greenbytes">greenbytes GmbH</organizati on>
<address> <address>
<postal> <postal>
<street>Hafenweg 16</street> <postalLine>Hafenweg 16</postalLine>
<city>Münster</city> <postalLine>48155 Münster</postalLine>
<code>48155</code> <postalLine>Germany</postalLine>
<country>Germany</country>
</postal> </postal>
<email>julian.reschke@greenbytes.de</email> <email>julian.reschke@greenbytes.de</email>
<uri>https://greenbytes.de/tech/webdav/</uri> <uri>https://greenbytes.de/tech/webdav/</uri>
</address> </address>
</author> </author>
<date year="2022" month="January"/> <date year="2022" month="January"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP Working Group</workgroup> <workgroup>HTTP Working Group</workgroup>
<keyword>Hypertext Transfer Protocol</keyword> <keyword>Hypertext Transfer Protocol</keyword>
<keyword>HTTP</keyword> <keyword>HTTP</keyword>
skipping to change at line 186 skipping to change at line 183
This included length-based data delimiters for both fixed and dynam ic This included length-based data delimiters for both fixed and dynam ic
(chunked) content, a consistent framework for content negotiation, (chunked) content, a consistent framework for content negotiation,
opaque validators for conditional requests, cache controls for bett er opaque validators for conditional requests, cache controls for bett er
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 publish ed on persistent connections. HTTP/1.1 was introduced in 1995 and publish ed 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="HTTP2"/> introduced a multiplexed session laye r HTTP/2 (<xref target="HTTP2"/>) introduced a multiplexed session la yer
on top of the existing TLS and TCP protocols for exchanging concurr ent on top of the existing TLS and TCP protocols for exchanging concurr ent
HTTP messages with efficient field compression and server push. HTTP messages with efficient field compression and server push.
HTTP/3 <xref target="HTTP3"/> provides greater independence for con current HTTP/3 (<xref target="HTTP3"/>) provides greater independence for c oncurrent
messages by using QUIC as a secure multiplexed transport over UDP i nstead of messages by using QUIC as a secure multiplexed transport over UDP i nstead 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 transpo rt and Implementations are expected to choose the most appropriate transpo rt 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 d ocument) This revision of HTTP separates the definition of semantics (this d ocument)
and caching <xref target="CACHING"/> from the current HTTP/1.1 mess and caching (<xref target="CACHING"/>) from the current HTTP/1.1 me
aging ssaging
syntax <xref target="HTTP11"/> to allow each major protocol version syntax (<xref target="HTTP11"/>) to allow each major protocol versi
on
to progress independently while referring to the same core semantic s. to progress independently while referring to the same core semantic s.
</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 1011 skipping to change at line 1008
</t> </t>
<iref primary="true" item="Grammar" subitem="URI-reference "/> <iref primary="true" item="Grammar" subitem="URI-reference "/>
<iref primary="true" item="Grammar" subitem="absolute-URI" /> <iref primary="true" item="Grammar" subitem="absolute-URI" />
<iref primary="true" item="Grammar" subitem="authority"/> <iref primary="true" item="Grammar" subitem="authority"/>
<iref primary="true" item="Grammar" subitem="absolute-path "/> <iref primary="true" item="Grammar" subitem="absolute-path "/>
<iref primary="true" item="Grammar" subitem="port"/> <iref primary="true" item="Grammar" subitem="port"/>
<iref primary="true" item="Grammar" subitem="query"/> <iref primary="true" item="Grammar" subitem="query"/>
<iref primary="true" item="Grammar" subitem="segment"/> <iref primary="true" item="Grammar" subitem="segment"/>
<iref primary="true" item="Grammar" subitem="uri-host"/> <iref primary="true" item="Grammar" subitem="uri-host"/>
<iref primary="true" item="Grammar" subitem="partial-URI"/ > <iref primary="true" item="Grammar" subitem="partial-URI"/ >
<sourcecode type="abnf7230"><![CDATA[ URI-reference = <UR I-reference, see [URI], Section 4.1> <sourcecode type="abnf9110"><![CDATA[ URI-reference = <UR I-reference, see [URI], Section 4.1>
absolute-URI = <absolute-URI, see [URI], Section 4.3> absolute-URI = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2> relative-part = <relative-part, see [URI], Section 4.2>
authority = <authority, see [URI], Section 3.2> authority = <authority, see [URI], Section 3.2>
uri-host = <host, see [URI], Section 3.2.2> uri-host = <host, see [URI], Section 3.2.2>
port = <port, see [URI], Section 3.2.3> port = <port, see [URI], Section 3.2.3>
path-abempty = <path-abempty, see [URI], Section 3.3> path-abempty = <path-abempty, see [URI], Section 3.3>
segment = <segment, see [URI], Section 3.3> segment = <segment, see [URI], Section 3.3>
query = <query, see [URI], Section 3.4> query = <query, see [URI], Section 3.4>
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
skipping to change at line 1120 skipping to change at line 1117
whether or not that server currently maps that identifier to a reso urce. whether or not that server currently maps that identifier to a reso urce.
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 wit hin the The "http" URI scheme is hereby defined for minting identifiers wit hin the
hierarchical namespace governed by a potential HTTP origin server hierarchical namespace governed by a potential HTTP origin server
listening for TCP <xref target="TCP"/> connections on a given port. listening for TCP (<xref target="TCP"/>) connections on a given por t.
</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 " "://" authority path-abempty [ "?" query ] <sourcecode type="abnf9110"><![CDATA[ http-URI = "http " "://" authority 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> compon ent, which includes a host identifier <xref target="uri.references" format="none">authority</xref> compon ent, which includes a host identifier
(<xref target="URI" sectionFormat="comma" section="3.2.2"/>) (<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
and optional port number (<xref target="URI" sectionFormat="comma" section="3.2.3"/>). and optional port number (<xref target="URI" sectionFormat="comma" section="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
skipping to change at line 1154 skipping to change at line 1151
</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 wi thin the The "https" URI scheme is hereby defined for minting identifiers wi thin the
hierarchical namespace governed by a potential origin server listen ing for hierarchical namespace governed by a potential origin server listen ing 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="TLS13"/> 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 ha s identified authority and all HTTP communication with that server ha s
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 = "htt ps" "://" authority path-abempty [ "?" query ] <sourcecode type="abnf9110"><![CDATA[ https-URI = "htt ps" "://" 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> compon ent, which includes a host identifier <xref target="uri.references" format="none">authority</xref> compon ent, which includes a host identifier
(<xref target="URI" sectionFormat="comma" section="3.2.2"/>) (<xref target="URI" sectionFormat="comma" section="3.2.2"/>)
and optional port number (<xref target="URI" sectionFormat="comma" section="3.2.3"/>). and optional port number (<xref target="URI" sectionFormat="comma" section="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
skipping to change at line 1575 skipping to change at line 1572
(<xref target="message.abstraction"/>). (<xref target="message.abstraction"/>).
</t> </t>
<section anchor="fields.names" title="Field Names"> <section anchor="fields.names" title="Field Names">
<t> <t>
A field name labels the corresponding field value as having the A field name labels the corresponding field value as having the
semantics defined by that name. For example, the <xref target="fie ld.date" format="none">Date</xref> semantics defined by that name. For example, the <xref target="fie ld.date" format="none">Date</xref>
header field is defined in <xref target="field.date"/> as containin g the header field is defined in <xref target="field.date"/> as containin g the
origination timestamp for the message in which it appears. origination timestamp for the message in which it appears.
</t> </t>
<iref primary="true" item="Grammar" subitem="field-name"/> <iref primary="true" item="Grammar" subitem="field-name"/>
<sourcecode type="abnf7230"><![CDATA[ field-name = to ken <sourcecode type="abnf9110"><![CDATA[ field-name = to ken
]]></sourcecode> ]]></sourcecode>
<t> <t>
Field names are case-insensitive and ought to be registered within the Field names are case-insensitive and ought to be registered within the
"Hypertext Transfer Protocol (HTTP) Field Name Registry"; see <xref target="fields.registry"/>. "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see <xref target="fields.registry"/>.
</t> </t>
<t> <t>
The interpretation of a field does not change between minor The interpretation of a field does not change between minor
versions of the same major HTTP version, though the default behavio r of a versions of the same major HTTP version, though the default behavio r of a
recipient in the absence of such a field can change. Unless specifi ed recipient in the absence of such a field can change. Unless specifi ed
otherwise, fields are defined for all versions of HTTP. otherwise, fields are defined for all versions of HTTP.
skipping to change at line 1665 skipping to change at line 1662
<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 fi eld's line of the same name already exists in the message, unless that fi eld'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 field <xref target="COOKIE"/> <strong>Note:</strong> In practice, the "Set-Cookie" header field (<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 f ield lines use the list syntax, violating the above requirements on multiple f ield 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 wh ile value, recipients ought to handle "Set-Cookie" as a special case wh ile
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 recei ved in a The order in which field lines with differing field names are recei ved in a
skipping to change at line 1715 skipping to change at line 1712
A client <bcp14>MAY</bcp14> discard or truncate received field line s that are larger A client <bcp14>MAY</bcp14> discard or truncate received field line s that are larger
than the client wishes to process if the field semantics are such t hat the than the client wishes to process if the field semantics are such t hat 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>
HTTP field values consist of a sequence of characters in a format d efined HTTP field values consist of a sequence of characters in a format d efined
by the field's grammar. Each field's grammar is usually defined usi ng by the field's grammar. Each field's grammar is usually defined usi ng
ABNF <xref target="RFC5234"/>. ABNF (<xref target="RFC5234"/>).
</t> </t>
<iref primary="true" item="Grammar" subitem="field-value"/ > <iref primary="true" item="Grammar" subitem="field-value"/ >
<iref primary="true" item="Grammar" subitem="field-vchar"/ > <iref primary="true" item="Grammar" subitem="field-vchar"/ >
<iref primary="true" item="Grammar" subitem="field-content "/> <iref primary="true" item="Grammar" subitem="field-content "/>
<iref primary="true" item="Grammar" subitem="obs-text"/> <iref primary="true" item="Grammar" subitem="obs-text"/>
<sourcecode type="abnf7230"><![CDATA[ field-value = *f ield-content <sourcecode type="abnf9110"><![CDATA[ field-value = *f ield-content
field-content = field-vchar field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ] [ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
obs-text = %x80-FF obs-text = %x80-FF
]]></sourcecode> ]]></sourcecode>
<t> <t>
A field value does not include leading or trailing whitespace. When a A field value does not include leading or trailing whitespace. When a
specific version of HTTP allows such whitespace to appear in a mess age, specific version of HTTP allows such whitespace to appear in a mess age,
a field parsing implementation <bcp14>MUST</bcp14> exclude such whi tespace prior to a field parsing implementation <bcp14>MUST</bcp14> exclude such whi tespace prior to
evaluating the field value. evaluating the field value.
skipping to change at line 1903 skipping to change at line 1900
</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
delimiters. delimiters.
</t> </t>
<iref primary="true" item="Grammar" subitem="token"/> <iref primary="true" item="Grammar" subitem="token"/>
<iref primary="true" item="Grammar" subitem="tchar"/> <iref primary="true" item="Grammar" subitem="tchar"/>
<sourcecode type="abnf7230"><![CDATA[ token = 1*tchar <sourcecode type="abnf9110"><![CDATA[ token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
; any VCHAR, except delimiters ; any VCHAR, except delimiters
]]></sourcecode> ]]></sourcecode>
<t anchor="delimiters"> <t anchor="delimiters">
<iref item="Delimiters"/> <iref item="Delimiters"/>
Many HTTP field values are defined using common syntax Many HTTP field values are defined using common syntax
components, separated by whitespace or specific delimiting characte rs. components, separated by whitespace or specific delimiting characte rs.
skipping to change at line 1955 skipping to change at line 1952
interpreting the protocol element. interpreting the protocol element.
</t> </t>
<t> <t>
BWS has no semantics. Any content known to be BWS has no semantics. Any content known to be
defined as BWS <bcp14>MAY</bcp14> be removed before interpreting it or forwarding the defined as BWS <bcp14>MAY</bcp14> be removed before interpreting it or forwarding the
message downstream. message downstream.
</t> </t>
<iref primary="true" item="Grammar" subitem="OWS"/> <iref primary="true" item="Grammar" subitem="OWS"/>
<iref primary="true" item="Grammar" subitem="RWS"/> <iref primary="true" item="Grammar" subitem="RWS"/>
<iref primary="true" item="Grammar" subitem="BWS"/> <iref primary="true" item="Grammar" subitem="BWS"/>
<sourcecode type="abnf7230"><![CDATA[ OWS = *( SP / HTAB ) <sourcecode type="abnf9110"><![CDATA[ OWS = *( SP / HTAB )
; optional whitespace ; optional whitespace
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
; required whitespace ; required whitespace
BWS = OWS BWS = OWS
; "bad" whitespace ; "bad" whitespace
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="quoted.strings" title="Quoted Strings"> <section anchor="quoted.strings" title="Quoted Strings">
<t anchor="rule.quoted-string"> <t anchor="rule.quoted-string">
A string of text is parsed as a single value if it is quoted using A string of text is parsed as a single value if it is quoted using
double-quote marks. double-quote marks.
</t> </t>
<iref primary="true" item="Grammar" subitem="quoted-str ing"/> <iref primary="true" item="Grammar" subitem="quoted-str ing"/>
<iref primary="true" item="Grammar" subitem="qdtext"/> <iref primary="true" item="Grammar" subitem="qdtext"/>
<sourcecode type="abnf7230"><![CDATA[ quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE <sourcecode type="abnf9110"><![CDATA[ quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.quoted-pair"> <t anchor="rule.quoted-pair">
The backslash octet ("\") can be used as a single-octet The backslash octet ("\") can be used as a single-octet
quoting mechanism within quoted-string and comment constructs. quoting mechanism within quoted-string and comment constructs.
Recipients that process the value of a quoted-string <bcp14>MUST</b cp14> handle a Recipients that process the value of a quoted-string <bcp14>MUST</b cp14> handle a
quoted-pair as if it were replaced by the octet following the backs lash. quoted-pair as if it were replaced by the octet following the backs lash.
</t> </t>
<iref primary="true" item="Grammar" subitem="quoted-pai r"/> <iref primary="true" item="Grammar" subitem="quoted-pai r"/>
<sourcecode type="abnf7230"><![CDATA[ quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) <sourcecode type="abnf9110"><![CDATA[ quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a quot ed-string except A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a quot ed-string except
where necessary to quote DQUOTE and backslash octets occurring with in that where necessary to quote DQUOTE and backslash octets occurring with in that
string. string.
A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a comm ent except A sender <bcp14>SHOULD NOT</bcp14> generate a quoted-pair in a comm ent except
where necessary to quote parentheses ["(" and ")"] and backslash oc tets where necessary to quote parentheses ["(" and ")"] and backslash oc tets
occurring within that comment. occurring within that comment.
</t> </t>
</section> </section>
<section anchor="comments" title="Comments"> <section anchor="comments" title="Comments">
<t anchor="rule.comment"> <t anchor="rule.comment">
Comments can be included in some HTTP fields by surrounding Comments can be included in some HTTP fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition . fields containing "comment" as part of their field value definition .
</t> </t>
<iref primary="true" item="Grammar" subitem="comment"/> <iref primary="true" item="Grammar" subitem="comment"/>
<iref primary="true" item="Grammar" subitem="ctext"/> <iref primary="true" item="Grammar" subitem="ctext"/>
<sourcecode type="abnf7230"><![CDATA[ comment = "(" *( ctext / quoted-pair / comment ) ")" <sourcecode type="abnf9110"><![CDATA[ comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="parameter" title="Parameters"> <section anchor="parameter" title="Parameters">
<t anchor="rule.parameter"> <t anchor="rule.parameter">
Parameters are instances of name=value pairs; they are often used i n field Parameters are instances of name=value pairs; they are often used i n field
values as a common syntax for appending auxiliary information to an item. values as a common syntax for appending auxiliary information to an item.
Each parameter is usually delimited by an immediately preceding sem icolon. Each parameter is usually delimited by an immediately preceding sem icolon.
</t> </t>
<iref primary="true" item="Grammar" subitem="parameters "/> <iref primary="true" item="Grammar" subitem="parameters "/>
<iref primary="true" item="Grammar" subitem="parameter" /> <iref primary="true" item="Grammar" subitem="parameter" />
<iref primary="true" item="Grammar" subitem="parameter- name"/> <iref primary="true" item="Grammar" subitem="parameter- name"/>
<iref primary="true" item="Grammar" subitem="parameter- value"/> <iref primary="true" item="Grammar" subitem="parameter- value"/>
<sourcecode type="abnf7230"><![CDATA[ parameters = *( OWS ";" OWS [ parameter ] ) <sourcecode type="abnf9110"><![CDATA[ parameters = *( OWS ";" OWS [ parameter ] )
parameter = parameter-name "=" parameter-value parameter = parameter-name "=" parameter-value
parameter-name = token parameter-name = token
parameter-value = ( token / quoted-string ) parameter-value = ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Parameter names are case-insensitive. Parameter values might or mig ht Parameter names are case-insensitive. Parameter values might or mig ht
not be case-sensitive, depending on the semantics of the parameter not be case-sensitive, depending on the semantics of the parameter
name. Examples of parameters and some equivalent forms can be seen in name. Examples of parameters and some equivalent forms can be seen in
media types (<xref target="media.type"/>) and the Accept header fie ld media types (<xref target="media.type"/>) and the Accept header fie ld
(<xref target="field.accept"/>). (<xref target="field.accept"/>).
skipping to change at line 2051 skipping to change at line 2048
<section anchor="http.date" title="Date/Time Formats"> <section anchor="http.date" title="Date/Time Formats">
<iref primary="true" item="clock"/> <iref primary="true" item="clock"/>
<t> <t>
Prior to 1995, there were three different formats commonly used by servers Prior to 1995, there were three different formats commonly used by servers
to communicate timestamps. For compatibility with old implementati ons, all to communicate timestamps. For compatibility with old implementati ons, all
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="abnf7230"><![CDATA[ HTTP-date = I MF-fixdate / obs-date <sourcecode type="abnf9110"><![CDATA[ HTTP-date = I MF-fixdate / obs-date
]]></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 type="example"><![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>
skipping to change at line 2099 skipping to change at line 2096
</t> </t>
<t> <t>
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a predece ssor three-letter abbreviation for Greenwich Mean Time, "GMT", a predece ssor
of the UTC name; values in the asctime format are assumed to be in UTC. of the UTC name; values in the asctime format are assumed to be in UTC.
</t> </t>
<t> <t>
A <em>clock</em> is an implementation capable of providing a A <em>clock</em> is an implementation capable of providing a
reasonable approximation of the current instant in UTC. reasonable approximation of the current instant in UTC.
A clock implementation ought to use NTP <xref target="RFC5905"/>, A clock implementation ought to use NTP (<xref target="RFC5905"/>),
or some similar protocol, to synchronize with UTC. or some similar protocol, to synchronize with UTC.
</t> </t>
<t anchor="preferred.date.format"> <t anchor="preferred.date.format">
Preferred format: Preferred format:
</t> </t>
<iref primary="true" item="Grammar" subitem="IMF-fixdat e"/> <iref primary="true" item="Grammar" subitem="IMF-fixdat e"/>
<iref primary="true" item="Grammar" subitem="date1"/> <iref primary="true" item="Grammar" subitem="date1"/>
<iref primary="true" item="Grammar" subitem="time-of-da y"/> <iref primary="true" item="Grammar" subitem="time-of-da y"/>
<iref primary="true" item="Grammar" subitem="hour"/> <iref primary="true" item="Grammar" subitem="hour"/>
<iref primary="true" item="Grammar" subitem="minute"/> <iref primary="true" item="Grammar" subitem="minute"/>
<iref primary="true" item="Grammar" subitem="second"/> <iref primary="true" item="Grammar" subitem="second"/>
<iref primary="true" item="Grammar" subitem="day-name"/ > <iref primary="true" item="Grammar" subitem="day-name"/ >
<iref primary="true" item="Grammar" subitem="day-name-l "/> <iref primary="true" item="Grammar" subitem="day-name-l "/>
<iref primary="true" item="Grammar" subitem="day"/> <iref primary="true" item="Grammar" subitem="day"/>
<iref primary="true" item="Grammar" subitem="month"/> <iref primary="true" item="Grammar" subitem="month"/>
<iref primary="true" item="Grammar" subitem="year"/> <iref primary="true" item="Grammar" subitem="year"/>
<iref primary="true" item="Grammar" subitem="GMT"/> <iref primary="true" item="Grammar" subitem="GMT"/>
<sourcecode type="abnf7230"><![CDATA[ IMF-fixdate = d ay-name "," SP date1 SP time-of-day SP GMT <sourcecode type="abnf9110"><![CDATA[ IMF-fixdate = d ay-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322] ; see Section 3.3 of [RFC5322]
day-name = %s"Mon" / %s"Tue" / %s"Wed" day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun" / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
date1 = day SP month SP year date1 = day SP month SP year
; e.g., 02 Jun 1982 ; e.g., 02 Jun 1982
day = 2DIGIT day = 2DIGIT
skipping to change at line 2148 skipping to change at line 2145
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
]]></sourcecode> ]]></sourcecode>
<t anchor="obsolete.date.formats"> <t anchor="obsolete.date.formats">
Obsolete formats: Obsolete formats:
</t> </t>
<iref primary="true" item="Grammar" subitem="obs-date"/ > <iref primary="true" item="Grammar" subitem="obs-date"/ >
<sourcecode type="abnf7230"><![CDATA[ obs-date = r fc850-date / asctime-date <sourcecode type="abnf9110"><![CDATA[ obs-date = r fc850-date / asctime-date
]]></sourcecode> ]]></sourcecode>
<iref primary="true" item="Grammar" subitem="rfc850-dat e"/> <iref primary="true" item="Grammar" subitem="rfc850-dat e"/>
<sourcecode type="abnf7230"><![CDATA[ rfc850-date = d ay-name-l "," SP date2 SP time-of-day SP GMT <sourcecode type="abnf9110"><![CDATA[ rfc850-date = d ay-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
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-da te"/> <iref primary="true" item="Grammar" subitem="asctime-da te"/>
<sourcecode type="abnf7230"><![CDATA[ asctime-date = d ay-name SP date3 SP time-of-day SP year <sourcecode type="abnf9110"><![CDATA[ asctime-date = d ay-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="CACHING" secti on="4.2"/> relaxes this for cache recipients. HTTP-date is case sensitive. Note that <xref target="CACHING" secti on="4.2"/> relaxes this for cache recipients.
</t> </t>
<t> <t>
A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-date beyond A sender <bcp14>MUST NOT</bcp14> generate additional whitespace in an HTTP-date 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">d ay</xref>, The semantics of <xref target="preferred.date.format" format="none" >day-name</xref>, <xref target="preferred.date.format" format="none">d ay</xref>,
skipping to change at line 2315 skipping to change at line 2312
<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="metho ds"/>), message control data includes a request method (<xref target="metho ds"/>),
request target (<xref target="target.resource"/>), and protocol ver sion request target (<xref target="target.resource"/>), and protocol ver sion
(<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 phra se, and a status code (<xref target="status.codes"/>), optional reason phra se, and
protocol version. protocol version.
</t> </t>
<t> <t>
In HTTP/1.1 <xref target="HTTP11"/> and earlier, control data is se In HTTP/1.1 (<xref target="HTTP11"/>) and earlier, control data is
nt sent
as the first line of a message. In HTTP/2 <xref target="HTTP2"/> an as the first line of a message. In HTTP/2 (<xref target="HTTP2"/>)
d and
HTTP/3 <xref target="HTTP3"/>, control data is sent as pseudo-heade HTTP/3 (<xref target="HTTP3"/>), control data is sent as pseudo-hea
r der
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 communi cation information to determine limitations or potential for later communi cation
with that sender. with that sender.
</t> </t>
<t> <t>
skipping to change at line 2630 skipping to change at line 2627
<iref primary="true" item="Fields" subitem="Date"/> <iref primary="true" item="Fields" subitem="Date"/>
<iref primary="true" item="Header Fields" subitem="Date "/> <iref primary="true" item="Header Fields" subitem="Date "/>
<iref primary="true" item="Date header field"/> <iref primary="true" item="Date header field"/>
<t> <t>
The "Date" header field represents the date and time at which The "Date" header field represents the date and time at which
the message was originated, having the same semantics as the Origin ation the message was originated, having the same semantics as the Origin ation
Date Field (orig-date) defined in <xref target="RFC5322" section="3 .6.1"/>. Date Field (orig-date) defined in <xref target="RFC5322" section="3 .6.1"/>.
The field value is an HTTP-date, as defined in <xref target="http.d ate"/>. The field value is an HTTP-date, as defined in <xref target="http.d ate"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Date"/> <iref primary="true" item="Grammar" subitem="Date"/>
<sourcecode type="abnf7230"><![CDATA[ Date = HTTP-date <sourcecode type="abnf9110"><![CDATA[ Date = HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Date: Tue, 15 Nov 1994 08:12:31 GMT <sourcecode type="http-message"><![CDATA[Date: Tue, 15 Nov 1994 08:12:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender that generates a Date header field <bcp14>SHOULD</bcp14> g enerate its A sender that generates a Date header field <bcp14>SHOULD</bcp14> g enerate its
field value as the best available approximation of the date and tim e of field value as the best available approximation of the date and tim e of
message generation. In theory, the date ought to represent the mome nt just message generation. In theory, the date ought to represent the mome nt just
skipping to change at line 2687 skipping to change at line 2684
<iref primary="true" item="Header Fields" subitem="Trai ler"/> <iref primary="true" item="Header Fields" subitem="Trai ler"/>
<iref primary="true" item="Trailer header field"/> <iref primary="true" item="Trailer header field"/>
<t> <t>
The "Trailer" header field provides a list of field names that the sender The "Trailer" header field provides a list of field names that the sender
anticipates sending as trailer fields within that message. This all ows a anticipates sending as trailer fields within that message. This all ows a
recipient to prepare for receipt of the indicated metadata before i t starts recipient to prepare for receipt of the indicated metadata before i t starts
processing the content. processing the content.
</t> </t>
<iref primary="true" item="Grammar" subitem="Trailer"/> <iref primary="true" item="Grammar" subitem="Trailer"/>
<iref primary="false" item="Grammar" subitem="field-nam e"/> <iref primary="false" item="Grammar" subitem="field-nam e"/>
<sourcecode type="abnf7230"><![CDATA[ Trailer = #field -name <sourcecode type="abnf9110"><![CDATA[ Trailer = #field -name
]]></sourcecode> ]]></sourcecode>
<t> <t>
For example, a sender might indicate that a signature will For example, a sender might indicate that a signature will
be computed as the content is being streamed and provide the final be computed as the content is being streamed and provide the final
signature as a trailer field. This allows a recipient to perform th e same signature as a trailer field. This allows a recipient to perform th e same
check on the fly as it receives the content. check on the fly as it receives the content.
</t> </t>
<t> <t>
A sender that intends to generate one or more trailer fields in a m essage A sender that intends to generate one or more trailer fields in a m essage
<bcp14>SHOULD</bcp14> generate a <xref target="field.trailer" forma t="none">Trailer</xref> header field in the header <bcp14>SHOULD</bcp14> generate a <xref target="field.trailer" forma t="none">Trailer</xref> header field in the header
skipping to change at line 2792 skipping to change at line 2789
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="HTTP2"/> and HTTP/3 <xref target="HTTP3"/>, 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="abnf9110"><![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 fi eld in a request request. A user agent <bcp14>MUST</bcp14> generate a Host header fi eld in a request
unless it sends that information as an ":authority" pseudo-header f ield. unless it sends that information as an ":authority" pseudo-header f ield.
A user agent that sends Host <bcp14>SHOULD</bcp14> send it as the f irst field in the A user agent that sends Host <bcp14>SHOULD</bcp14> send it as the f irst field in the
header section of a request. header section of a request.
</t> </t>
<t> <t>
For example, a GET request to the origin server for For example, a GET request to the origin server for
skipping to change at line 3011 skipping to change at line 3008
<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="HTTP11" 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 = #connection-option <sourcecode type="abnf9110"><![CDATA[ Connection = #connection-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 correspon ding to a A sender <bcp14>MUST NOT</bcp14> send a connection option correspon ding 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="CACHING" section="5.2"/>). connection option (<xref target="CACHING" section="5.2"/>).
skipping to change at line 3066 skipping to change at line 3063
<iref primary="true" item="Header Fields" subitem="Max- Forwards"/> <iref primary="true" item="Header Fields" subitem="Max- Forwards"/>
<iref primary="true" item="Max-Forwards header field"/> <iref primary="true" item="Max-Forwards header field"/>
<t> <t>
The "Max-Forwards" header field provides a mechanism with the The "Max-Forwards" header field provides a mechanism with the
TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/ >) TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/ >)
request methods to limit the number of times that the request is fo rwarded by request methods to limit the number of times that the request is fo rwarded by
proxies. This can be useful when the client is attempting to proxies. This can be useful when the client is attempting to
trace a request that appears to be failing or looping mid-chain. trace a request that appears to be failing or looping mid-chain.
</t> </t>
<iref primary="true" item="Grammar" subitem="Max-Forwar ds"/> <iref primary="true" item="Grammar" subitem="Max-Forwar ds"/>
<sourcecode type="abnf7230"><![CDATA[ Max-Forwards = 1 *DIGIT <sourcecode type="abnf9110"><![CDATA[ Max-Forwards = 1 *DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Max-Forwards value is a decimal integer indicating the remainin g The Max-Forwards value is a decimal integer indicating the remainin g
number of times this request message can be forwarded. number of times this request message can be forwarded.
</t> </t>
<t> <t>
Each intermediary that receives a TRACE or OPTIONS request containi ng a Each intermediary that receives a TRACE or OPTIONS request containi ng a
Max-Forwards header field <bcp14>MUST</bcp14> check and update its value prior to Max-Forwards header field <bcp14>MUST</bcp14> check and update its value prior to
forwarding the request. If the received value is zero (0), the inte rmediary forwarding the request. If the received value is zero (0), the inte rmediary
<bcp14>MUST NOT</bcp14> forward the request; instead, the intermedi ary <bcp14>MUST</bcp14> respond as <bcp14>MUST NOT</bcp14> forward the request; instead, the intermedi ary <bcp14>MUST</bcp14> respond as
skipping to change at line 3108 skipping to change at line 3105
Via can be used for tracking message forwards, Via can be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities o f avoiding request loops, and identifying the protocol capabilities o f
senders along the request/response chain. senders along the request/response chain.
</t> </t>
<iref primary="true" item="Grammar" subitem="Via"/> <iref primary="true" item="Grammar" subitem="Via"/>
<iref primary="true" item="Grammar" subitem="received-p rotocol"/> <iref primary="true" item="Grammar" subitem="received-p rotocol"/>
<iref primary="true" item="Grammar" subitem="protocol-n ame"/> <iref primary="true" item="Grammar" subitem="protocol-n ame"/>
<iref primary="true" item="Grammar" subitem="protocol-v ersion"/> <iref primary="true" item="Grammar" subitem="protocol-v ersion"/>
<iref primary="true" item="Grammar" subitem="received-b y"/> <iref primary="true" item="Grammar" subitem="received-b y"/>
<iref primary="true" item="Grammar" subitem="pseudonym" /> <iref primary="true" item="Grammar" subitem="pseudonym" />
<sourcecode type="abnf7230"><![CDATA[ Via = #( receive d-protocol RWS received-by [ RWS comment ] ) <sourcecode type="abnf9110"><![CDATA[ Via = #( receive d-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
; see Section 7.8 ; see Section 7.8
received-by = pseudonym [ ":" port ] received-by = pseudonym [ ":" port ]
pseudonym = token pseudonym = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each member of the Via field value represents a proxy or gateway th at has Each member of the Via field value represents a proxy or gateway th at has
forwarded the message. Each intermediary appends its own informatio n forwarded the message. Each intermediary appends its own informatio n
about how the message was received, such that the end result is ord ered about how the message was received, such that the end result is ord ered
skipping to change at line 3271 skipping to change at line 3268
</t> </t>
<t> <t>
A client <bcp14>MAY</bcp14> send a list of protocol names in the Up grade header field A client <bcp14>MAY</bcp14> send a list of protocol names in the Up grade header field
of a request to invite the server to switch to one or more of the n amed of a request to invite the server to switch to one or more of the n amed
protocols, in order of descending preference, before sending protocols, in order of descending preference, before sending
the final response. A server <bcp14>MAY</bcp14> ignore a received U pgrade header field the final response. A server <bcp14>MAY</bcp14> ignore a received U pgrade header field
if it wishes to continue using the current protocol on that connect ion. if it wishes to continue using the current protocol on that connect ion.
Upgrade cannot be used to insist on a protocol change. Upgrade cannot be used to insist on a protocol change.
</t> </t>
<iref primary="true" item="Grammar" subitem="Upgrade"/> <iref primary="true" item="Grammar" subitem="Upgrade"/>
<sourcecode type="abnf7230"><![CDATA[ Upgrade = #protocol <sourcecode type="abnf9110"><![CDATA[ Upgrade = #protocol
protocol = protocol-name ["/" protocol-version] protocol = protocol-name ["/" protocol-version]
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
Although protocol names are registered with a preferred case, Although protocol names are registered with a preferred case,
recipients <bcp14>SHOULD</bcp14> use case-insensitive comparison wh en matching each recipients <bcp14>SHOULD</bcp14> use case-insensitive comparison wh en matching each
protocol-name to supported protocols. protocol-name to supported protocols.
</t> </t>
skipping to change at line 3417 skipping to change at line 3414
<t> <t>
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in associated representation: either the representation enclosed in
the message content or the <xref target="selected.representation" f ormat="none">selected representation</xref>, as determined by the the message content or the <xref target="selected.representation" f ormat="none">selected representation</xref>, as determined by the
message semantics. The indicated media type defines both the data format message semantics. The indicated media type defines both the data format
and how that data is intended to be processed by a recipient, withi n the and how that data is intended to be processed by a recipient, withi n the
scope of the received message semantics, after any content codings scope of the received message semantics, after any content codings
indicated by <xref target="field.content-encoding" format="none">Co ntent-Encoding</xref> are decoded. indicated by <xref target="field.content-encoding" format="none">Co ntent-Encoding</xref> are decoded.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Type" /> <iref primary="true" item="Grammar" subitem="Content-Type" />
<sourcecode type="abnf7230"><![CDATA[ Content-Type = medi a-type <sourcecode type="abnf9110"><![CDATA[ Content-Type = medi a-type
]]></sourcecode> ]]></sourcecode>
<t> <t>
Media types are defined in <xref target="media.type"/>. An example of the Media types are defined in <xref target="media.type"/>. An example of the
field is field is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Type: tex t/html; charset=ISO-8859-4 <sourcecode type="http-message"><![CDATA[Content-Type: tex t/html; charset=ISO-8859-4
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender that generates a message containing content <bcp14>SHOULD< /bcp14> A sender that generates a message containing content <bcp14>SHOULD< /bcp14>
generate a Content-Type header field in that message unless the int ended generate a Content-Type header field in that message unless the int ended
skipping to change at line 3469 skipping to change at line 3466
HTTP uses media types <xref target="RFC2046"/> in the HTTP uses media types <xref target="RFC2046"/> in the
<xref target="field.content-type" format="none">Content-Type</xref> (<xref target="field.content-type"/>) <xref target="field.content-type" format="none">Content-Type</xref> (<xref target="field.content-type"/>)
and <xref target="field.accept" format="none">Accept</xref> (<xref target="field.accept"/>) header fields in and <xref target="field.accept" format="none">Accept</xref> (<xref target="field.accept"/>) header fields in
order to provide open and extensible data typing and type negotiati on. order to provide open and extensible data typing and type negotiati on.
Media types define both a data format and various processing models : Media types define both a data format and various processing models :
how to process that data in accordance with the message context. how to process that data in accordance with the message context.
</t> </t>
<iref primary="true" item="Grammar" subitem="media-type "/> <iref primary="true" item="Grammar" subitem="media-type "/>
<iref primary="true" item="Grammar" subitem="type"/> <iref primary="true" item="Grammar" subitem="type"/>
<iref primary="true" item="Grammar" subitem="subtype"/> <iref primary="true" item="Grammar" subitem="subtype"/>
<sourcecode type="abnf7230"><![CDATA[ media-type = typ e "/" subtype parameters <sourcecode type="abnf9110"><![CDATA[ media-type = typ e "/" subtype parameters
type = token type = token
subtype = token subtype = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
The type and subtype tokens are case-insensitive. The type and subtype tokens are case-insensitive.
</t> </t>
<t> <t>
The type/subtype <bcp14>MAY</bcp14> be followed by semicolon-delimi ted parameters The type/subtype <bcp14>MAY</bcp14> be followed by semicolon-delimi ted parameters
(<xref target="parameter"/>) in the form of name=value pairs. (<xref target="parameter"/>) in the form of name=value pairs.
The presence or absence of a parameter might be significant to the The presence or absence of a parameter might be significant to the
skipping to change at line 3570 skipping to change at line 3567
<t> <t>
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in t he media have been applied to the representation, beyond those inherent in t he media
type, and thus what decoding mechanisms have to be applied in order to type, and thus what decoding mechanisms have to be applied in order to
obtain data in the media type referenced by the <xref target="field .content-type" format="none">Content-Type</xref> obtain data in the media type referenced by the <xref target="field .content-type" format="none">Content-Type</xref>
header field. header field.
Content-Encoding is primarily used to allow a representation's data to be Content-Encoding is primarily used to allow a representation's data to be
compressed without losing the identity of its underlying media type . compressed without losing the identity of its underlying media type .
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Encod ing"/> <iref primary="true" item="Grammar" subitem="Content-Encod ing"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Encoding = #content-coding <sourcecode type="abnf9110"><![CDATA[ Content-Encoding = #content-coding
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of its use is An example of its use is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Encoding: gzip <sourcecode type="http-message"><![CDATA[Content-Encoding: gzip
]]></sourcecode> ]]></sourcecode>
<t> <t>
If one or more encodings have been applied to a representation, the sender If one or more encodings have been applied to a representation, the sender
that applied the encodings <bcp14>MUST</bcp14> generate a Content-E ncoding header field that applied the encodings <bcp14>MUST</bcp14> generate a Content-E ncoding header field
that lists the content codings in the order in which they were appl ied. that lists the content codings in the order in which they were appl ied.
skipping to change at line 3630 skipping to change at line 3627
<iref primary="true" item="x-gzip (content coding)"/> <iref primary="true" item="x-gzip (content coding)"/>
<t> <t>
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are pri marily been or can be applied to a representation. Content codings are pri marily
used to allow a representation to be compressed or otherwise useful ly used to allow a representation to be compressed or otherwise useful ly
transformed without losing the identity of its underlying media typ e transformed without losing the identity of its underlying media typ e
and without loss of information. Frequently, the representation is stored and without loss of information. Frequently, the representation is stored
in coded form, transmitted directly, and only decoded by the final recipient. in coded form, transmitted directly, and only decoded by the final recipient.
</t> </t>
<iref primary="true" item="Grammar" subitem="content-co ding"/> <iref primary="true" item="Grammar" subitem="content-co ding"/>
<sourcecode type="abnf7230"><![CDATA[ content-coding = token <sourcecode type="abnf9110"><![CDATA[ content-coding = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
All content codings are case-insensitive and ought to be registered All content codings are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as described in within the "HTTP Content Coding Registry", as described in
<xref target="content.coding.extensibility"/> <xref target="content.coding.extensibility"/>
</t> </t>
<t> <t>
Content-coding values are used in the Content-coding values are used in the
<xref target="field.accept-encoding" format="none">Accept-Encoding< /xref> (<xref target="field.accept-encoding"/>) <xref target="field.accept-encoding" format="none">Accept-Encoding< /xref> (<xref target="field.accept-encoding"/>)
and <xref target="field.content-encoding" format="none">Content-Enc oding</xref> (<xref target="field.content-encoding"/>) and <xref target="field.content-encoding" format="none">Content-Enc oding</xref> (<xref target="field.content-encoding"/>)
skipping to change at line 3688 skipping to change at line 3685
<section anchor="field.content-language" title="Content-Langu age"> <section anchor="field.content-language" title="Content-Langu age">
<iref primary="true" item="Fields" subitem="Content-Langua ge"/> <iref primary="true" item="Fields" subitem="Content-Langua ge"/>
<iref primary="true" item="Header Fields" subitem="Content -Language"/> <iref primary="true" item="Header Fields" subitem="Content -Language"/>
<iref primary="true" item="Content-Language header field"/ > <iref primary="true" item="Content-Language header field"/ >
<t> <t>
The "Content-Language" header field describes the natural The "Content-Language" header field describes the natural
language(s) of the intended audience for the representation. Note t hat this might language(s) of the intended audience for the representation. Note t hat this might
not be equivalent to all the languages used within the representati on. not be equivalent to all the languages used within the representati on.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Langu age"/> <iref primary="true" item="Grammar" subitem="Content-Langu age"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Language = #language-tag <sourcecode type="abnf9110"><![CDATA[ Content-Language = #language-tag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Language tags are defined in <xref target="language.tags"/>. The pr imary purpose of Language tags are defined in <xref target="language.tags"/>. The pr imary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. Thu s, if the representations according to the users' own preferred language. Thu s, if the
content is intended only for a Danish-literate audience, the content is intended only for a Danish-literate audience, the
appropriate field is appropriate field is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Language: da <sourcecode type="http-message"><![CDATA[Content-Language: da
]]></sourcecode> ]]></sourcecode>
skipping to change at line 3741 skipping to change at line 3738
</t> </t>
<t> <t>
HTTP uses language tags within the <xref target="field.accept-langu age" format="none">Accept-Language</xref> and HTTP uses language tags within the <xref target="field.accept-langu age" format="none">Accept-Language</xref> and
<xref target="field.content-language" format="none">Content-Languag e</xref> header fields. <xref target="field.content-language" format="none">Content-Languag e</xref> header fields.
<xref target="field.accept-language" format="none">Accept-Language< /xref> uses the broader language-range production <xref target="field.accept-language" format="none">Accept-Language< /xref> uses the broader language-range production
defined in <xref target="field.accept-language"/>, whereas defined in <xref target="field.accept-language"/>, whereas
<xref target="field.content-language" format="none">Content-Languag e</xref> uses the language-tag production defined <xref target="field.content-language" format="none">Content-Languag e</xref> uses the language-tag production defined
below. below.
</t> </t>
<iref primary="true" item="Grammar" subitem="language-t ag"/> <iref primary="true" item="Grammar" subitem="language-t ag"/>
<sourcecode type="abnf7230"><![CDATA[ language-tag = < Language-Tag, see [RFC5646], Section 2.1> <sourcecode type="abnf9110"><![CDATA[ language-tag = < Language-Tag, see [RFC5646], Section 2.1>
]]></sourcecode> ]]></sourcecode>
<t> <t>
A language tag is a sequence of one or more case-insensitive subtag s, each A language tag is a sequence of one or more case-insensitive subtag s, each
separated by a hyphen character ("-", %x2D). In most cases, a lang uage tag separated by a hyphen character ("-", %x2D). In most cases, a lang uage tag
consists of a primary language subtag that identifies a broad famil y of consists of a primary language subtag that identifies a broad famil y of
related languages (e.g., "en" = English), which is optionally follo wed by a related languages (e.g., "en" = English), which is optionally follo wed 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:
skipping to change at line 3776 skipping to change at line 3773
The "Content-Length" header field indicates the associated represen tation's The "Content-Length" header field indicates the associated represen tation'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 refer s When transferring a representation as content, Content-Length refer s
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="HTTP11" section="6.2"/>). delimit framing (e.g., <xref target="HTTP11" section="6.2"/>).
In other cases, Content-Length indicates the selected representatio n's In other cases, Content-Length indicates the selected representatio n's
current length, which can be used by recipients to estimate transfe r time current length, which can be used by recipients to estimate transfe r time
or to compare to previously stored representations. or to compare to previously stored representations.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Lengt h"/> <iref primary="true" item="Grammar" subitem="Content-Lengt h"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Length = 1* DIGIT <sourcecode type="abnf9110"><![CDATA[ Content-Length = 1* DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Content-Length: 3 495 <sourcecode type="http-message"><![CDATA[Content-Length: 3 495
]]></sourcecode> ]]></sourcecode>
<t> <t>
A user agent <bcp14>SHOULD</bcp14> send Content-Length in a request when the method A user agent <bcp14>SHOULD</bcp14> send Content-Length in a request when the method
defines a meaning for enclosed content and it is not sending defines a meaning for enclosed content and it is not sending
Transfer-Encoding. Transfer-Encoding.
skipping to change at line 3867 skipping to change at line 3864
<iref primary="true" item="Content-Location header field"/ > <iref primary="true" item="Content-Location header field"/ >
<t> <t>
The "Content-Location" header field references a URI that can be us ed The "Content-Location" header field references a URI that can be us ed
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's content. representation in this message's content.
In other words, if one were to perform a GET request on this URI at the time In other words, if one were to perform a GET request on this URI at the time
of this message's generation, then a <xref target="status.200" form at="none">200 (OK)</xref> response would of this message's generation, then a <xref target="status.200" form at="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-Locat ion"/> <iref primary="true" item="Grammar" subitem="Content-Locat ion"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Location = absolute-URI / partial-URI <sourcecode type="abnf9110"><![CDATA[ Content-Location = absolute-URI / partial-URI
]]></sourcecode> ]]></sourcecode>
<t> <t>
The field value is either an <xref target="uri.references" format=" none">absolute-URI</xref> or a The field value is either an <xref target="uri.references" format=" none">absolute-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="URI" 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.
skipping to change at line 4103 skipping to change at line 4100
<iref primary="true" item="Fields" subitem="Last-Modifi ed"/> <iref primary="true" item="Fields" subitem="Last-Modifi ed"/>
<iref primary="true" item="Header Fields" subitem="Last -Modified"/> <iref primary="true" item="Header Fields" subitem="Last -Modified"/>
<iref primary="true" item="Last-Modified header field"/ > <iref primary="true" item="Last-Modified header field"/ >
<t> <t>
The "Last-Modified" header field in a response provides a timestamp The "Last-Modified" header field in a response provides a timestamp
indicating the date and time at which the origin server believes th e indicating the date and time at which the origin server believes th e
<xref target="selected.representation" format="none">selected repre sentation</xref> was last modified, as determined at the conclusion <xref target="selected.representation" format="none">selected repre sentation</xref> was last modified, as determined at the conclusion
of handling the request. of handling the request.
</t> </t>
<iref primary="true" item="Grammar" subitem="Last-Modif ied"/> <iref primary="true" item="Grammar" subitem="Last-Modif ied"/>
<sourcecode type="abnf7230"><![CDATA[ Last-Modified = HTTP-date <sourcecode type="abnf9110"><![CDATA[ Last-Modified = HTTP-date
]]></sourcecode> ]]></sourcecode>
<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 Nov 1994 12:45:26 GMT <sourcecode type="http-message"><![CDATA[Last-Modified: Tue, 15 Nov 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 s elected An origin server <bcp14>SHOULD</bcp14> send Last-Modified for any s elected
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="CACHING"/> 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 4220 skipping to change at line 4217
those multiple representations are due to resource state changes ov er those multiple representations are due to resource state changes ov er
time, content negotiation resulting in multiple representations bei ng time, content negotiation resulting in multiple representations bei ng
valid at the same time, or both. An entity-tag consists of an opaqu e valid at the same time, or both. An entity-tag consists of an opaqu e
quoted string, possibly prefixed by a weakness indicator. quoted string, possibly prefixed by a weakness indicator.
</t> </t>
<iref primary="true" item="Grammar" subitem="ETag"/> <iref primary="true" item="Grammar" subitem="ETag"/>
<iref primary="true" item="Grammar" subitem="entity-tag "/> <iref primary="true" item="Grammar" subitem="entity-tag "/>
<iref primary="true" item="Grammar" subitem="weak"/> <iref primary="true" item="Grammar" subitem="weak"/>
<iref primary="true" item="Grammar" subitem="opaque-tag "/> <iref primary="true" item="Grammar" subitem="opaque-tag "/>
<iref primary="true" item="Grammar" subitem="etagc"/> <iref primary="true" item="Grammar" subitem="etagc"/>
<sourcecode type="abnf7230"><![CDATA[ ETag = ent ity-tag <sourcecode type="abnf9110"><![CDATA[ ETag = ent ity-tag
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = %s"W/" weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text ; VCHAR except double quotes, plus obs-text
]]></sourcecode> ]]></sourcecode>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Previously, opaque-tag was defined to be a quoted-string <strong>Note:</strong> Previously, opaque-tag was defined to be a quoted-string
skipping to change at line 4286 skipping to change at line 4283
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, o r representation content, a combination of various file attributes, o r
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 selecte d representation An origin server <bcp14>SHOULD</bcp14> send an ETag for any selecte d representation
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="CACHING"/> 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="Comparis on"> <section anchor="entity.tag.comparison" title="Comparis on">
<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 4440 skipping to change at line 4437
(<xref target="preconditions"/>) to make the requested (<xref target="preconditions"/>) to make the requested
action conditional on the current state of the target resource. action conditional on the current state of the target resource.
</t> </t>
<t> <t>
HTTP is designed to be usable as an interface to distributed HTTP is designed to be usable as an interface to distributed
object systems. The request method invokes an action to be applied to object systems. The request method invokes an action to be applied to
a <xref target="target.resource" format="none">target resource</xre f> in much the same way that a remote a <xref target="target.resource" format="none">target resource</xre f> in much the same way that a remote
method invocation can be sent to an identified object. method invocation can be sent to an identified object.
</t> </t>
<iref primary="true" item="Grammar" subitem="method"/> <iref primary="true" item="Grammar" subitem="method"/>
<sourcecode type="abnf7230"><![CDATA[ method = token <sourcecode type="abnf9110"><![CDATA[ method = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
The method token is case-sensitive because it might be used as a ga teway The method token is case-sensitive because it might be used as a ga teway
to object-based systems with case-sensitive method names. By conven tion, to object-based systems with case-sensitive method names. By conven tion,
standardized methods are defined in all-uppercase US-ASCII letters. standardized methods are defined in all-uppercase US-ASCII letters.
</t> </t>
<t> <t>
Unlike distributed objects, the standardized request methods in HTT P are Unlike distributed objects, the standardized request methods in HTT P are
not resource-specific, since uniform interfaces provide for better not resource-specific, since uniform interfaces provide for better
visibility and reuse in network-based systems <xref target="REST"/> . visibility and reuse in network-based systems <xref target="REST"/> .
skipping to change at line 5264 skipping to change at line 5261
<iref primary="true" item="Fields" subitem="Expect"/> <iref primary="true" item="Fields" subitem="Expect"/>
<iref primary="true" item="Header Fields" subitem="Expe ct"/> <iref primary="true" item="Header Fields" subitem="Expe ct"/>
<iref primary="true" item="Expect header field"/> <iref primary="true" item="Expect header field"/>
<iref primary="true" item="100-continue (expect value)" /> <iref primary="true" item="100-continue (expect value)" />
<t> <t>
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. order to properly handle this request.
</t> </t>
<iref primary="true" item="Grammar" subitem="Expect"/> <iref primary="true" item="Grammar" subitem="Expect"/>
<sourcecode type="abnf7230"><![CDATA[ Expect = #e xpectation <sourcecode type="abnf9110"><![CDATA[ Expect = #e xpectation
expectation = token [ "=" ( token / quoted-string ) parameters ] expectation = token [ "=" ( token / quoted-string ) parameters ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Expect field value is case-insensitive. The Expect field value is case-insensitive.
</t> </t>
<t> <t>
The only expectation defined by this specification is "100-continue " The only expectation defined by this specification is "100-continue "
(with no defined parameters). (with no defined parameters).
</t> </t>
<t> <t>
skipping to change at line 5451 skipping to change at line 5448
<iref primary="true" item="Fields" subitem="From"/> <iref primary="true" item="Fields" subitem="From"/>
<iref primary="true" item="Header Fields" subitem="From "/> <iref primary="true" item="Header Fields" subitem="From "/>
<iref primary="true" item="From header field"/> <iref primary="true" item="From header field"/>
<t> <t>
The "From" header field contains an Internet email address for a hu man The "From" header field contains an Internet email address for a hu man
user who controls the requesting user agent. The address ought to b e user who controls the requesting user agent. The address ought to b e
machine-usable, as defined by "mailbox" machine-usable, as defined by "mailbox"
in <xref target="RFC5322" section="3.4"/>: in <xref target="RFC5322" section="3.4"/>:
</t> </t>
<iref primary="true" item="Grammar" subitem="From"/> <iref primary="true" item="Grammar" subitem="From"/>
<sourcecode type="abnf7230"><![CDATA[ From = mailbo x <sourcecode type="abnf9110"><![CDATA[ From = mailbo x
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example is: An example is:
</t> </t>
<sourcecode type="http-message"><![CDATA[From: webmaste r@example.org <sourcecode type="http-message"><![CDATA[From: webmaste r@example.org
]]></sourcecode> ]]></sourcecode>
<t> <t>
The From header field is rarely sent by non-robotic user agents. The From header field is rarely sent by non-robotic user agents.
skipping to change at line 5492 skipping to change at line 5489
<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.reso urce" format="none">target URI</xref> was reference for the resource from which the <xref target="target.reso urce" format="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 useri nfo components A user agent <bcp14>MUST NOT</bcp14> include the fragment and useri nfo components
of the URI reference <xref target="URI"/>, 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 = absolu te-URI / partial-URI <sourcecode type="abnf9110"><![CDATA[ Referer = absolu te-URI / partial-URI
]]></sourcecode> ]]></sourcecode>
<t> <t>
The field value is either an <xref target="uri.references" format=" none">absolute-URI</xref> or a The field value is either an <xref target="uri.references" format=" none">absolute-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="URI" 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 o ther The Referer header field allows servers to generate back-links to o ther
resources for simple analytics, logging, optimized caching, etc. It also resources for simple analytics, logging, optimized caching, etc. It also
skipping to change at line 5582 skipping to change at line 5579
The TE field value is a list of members, with each member (aside fr om The TE field value is a list of members, with each member (aside fr om
"trailers") consisting of a transfer coding name token with an opti onal "trailers") consisting of a transfer coding name token with an opti onal
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" />
<iref primary="true" item="Grammar" subitem="transfer-c oding"/> <iref primary="true" item="Grammar" subitem="transfer-c oding"/>
<iref primary="true" item="Grammar" subitem="transfer-p arameter"/> <iref primary="true" item="Grammar" subitem="transfer-p arameter"/>
<sourcecode type="abnf7230"><![CDATA[ TE = #t-codings <sourcecode type="abnf9110"><![CDATA[ TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ weight ] ) t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter ) transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender of TE <bcp14>MUST</bcp14> also send a "TE" connection opti on within the A sender of TE <bcp14>MUST</bcp14> also send a "TE" connection opti on within the
<xref target="field.connection" format="none">Connection</xref> hea der field (<xref target="field.connection"/>) <xref target="field.connection" format="none">Connection</xref> hea der field (<xref target="field.connection"/>)
to inform intermediaries not to forward this field. to inform intermediaries not to forward this field.
</t> </t>
</section> </section>
skipping to change at line 5607 skipping to change at line 5604
<t> <t>
The "User-Agent" header field contains information about the user a gent The "User-Agent" header field contains information about the user a gent
originating the request, which is often used by servers to help ide ntify originating the request, which is often used by servers to help ide ntify
the scope of reported interoperability problems, to work around or tailor the scope of reported interoperability problems, to work around or tailor
responses to avoid particular user agent limitations, and for analy tics responses to avoid particular user agent limitations, and for analy tics
regarding browser or operating system use. A user agent <bcp14>SHOU LD</bcp14> send regarding browser or operating system use. A user agent <bcp14>SHOU LD</bcp14> send
a User-Agent header field in each request unless specifically confi gured not a User-Agent header field in each request unless specifically confi gured not
to do so. to do so.
</t> </t>
<iref primary="true" item="Grammar" subitem="User-Agent "/> <iref primary="true" item="Grammar" subitem="User-Agent "/>
<sourcecode type="abnf7230"><![CDATA[ User-Agent = pro duct *( RWS ( product / comment ) ) <sourcecode type="abnf9110"><![CDATA[ User-Agent = pro duct *( RWS ( product / comment ) )
]]></sourcecode> ]]></sourcecode>
<t> <t>
The User-Agent field value consists of one or more product identifi ers, The User-Agent field value consists of one or more product identifi ers,
each followed by zero or more comments (<xref target="comments"/>), which together each followed by zero or more comments (<xref target="comments"/>), which together
identify the user agent software and its significant subproducts. identify the user agent software and its significant subproducts.
By convention, the product identifiers are listed in decreasing ord er of By convention, the product identifiers are listed in decreasing ord er of
their significance for identifying the user agent software. Each pr oduct their significance for identifying the user agent software. Each pr oduct
identifier consists of a name and optional version. identifier consists of a name and optional version.
</t> </t>
<iref primary="true" item="Grammar" subitem="product"/> <iref primary="true" item="Grammar" subitem="product"/>
<iref primary="true" item="Grammar" subitem="product-ve rsion"/> <iref primary="true" item="Grammar" subitem="product-ve rsion"/>
<sourcecode type="abnf7230"><![CDATA[ product = token ["/" product-version] <sourcecode type="abnf9110"><![CDATA[ product = token ["/" product-version]
product-version = token product-version = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender <bcp14>SHOULD</bcp14> limit generated product identifiers to what is necessary A sender <bcp14>SHOULD</bcp14> limit generated product identifiers to what is necessary
to identify the product; a sender <bcp14>MUST NOT</bcp14> generate advertising or other to identify the product; a sender <bcp14>MUST NOT</bcp14> generate advertising or other
nonessential information within the product identifier. nonessential information within the product identifier.
A sender <bcp14>SHOULD NOT</bcp14> generate information in <xref ta rget="field.user-agent" format="none">product-version</xref> A sender <bcp14>SHOULD NOT</bcp14> generate information in <xref ta rget="field.user-agent" format="none">product-version</xref>
that is not a version identifier (i.e., successive versions of the same that is not a version identifier (i.e., successive versions of the same
product name ought to differ only in the product-version portion of the product name ought to differ only in the product-version portion of the
product identifier). product identifier).
skipping to change at line 5671 skipping to change at line 5668
<iref primary="true" item="Fields" subitem="Allow"/> <iref primary="true" item="Fields" subitem="Allow"/>
<iref primary="true" item="Header Fields" subitem="Allo w"/> <iref primary="true" item="Header Fields" subitem="Allo w"/>
<iref primary="true" item="Allow header field"/> <iref primary="true" item="Allow header field"/>
<t> <t>
The "Allow" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised as
supported by the <xref target="target.resource" format="none">targe t resource</xref>. The purpose of this field supported by the <xref target="target.resource" format="none">targe t resource</xref>. The purpose of this field
is strictly to inform the recipient of valid request methods associ ated is strictly to inform the recipient of valid request methods associ ated
with the resource. with the resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Allow"/> <iref primary="true" item="Grammar" subitem="Allow"/>
<sourcecode type="abnf7230"><![CDATA[ Allow = #method <sourcecode type="abnf9110"><![CDATA[ Allow = #method
]]></sourcecode> ]]></sourcecode>
<t> <t>
Example of use: Example of use:
</t> </t>
<sourcecode type="http-message"><![CDATA[Allow: GET, HE AD, PUT <sourcecode type="http-message"><![CDATA[Allow: GET, HE AD, PUT
]]></sourcecode> ]]></sourcecode>
<t> <t>
The actual set of allowed methods is defined by the origin server a t the The actual set of allowed methods is defined by the origin server a t the
time of each request. An origin server <bcp14>MUST</bcp14> generate an Allow header field in a time of each request. An origin server <bcp14>MUST</bcp14> generate an Allow header field in a
<xref target="status.405" format="none">405 (Method Not Allowed)</x ref> response and <bcp14>MAY</bcp14> do so in any <xref target="status.405" format="none">405 (Method Not Allowed)</x ref> response and <bcp14>MAY</bcp14> do so in any
skipping to change at line 5702 skipping to change at line 5699
<section anchor="field.location" title="Location"> <section anchor="field.location" title="Location">
<iref primary="true" item="Fields" subitem="Location"/> <iref primary="true" item="Fields" subitem="Location"/>
<iref primary="true" item="Header Fields" subitem="Loca tion"/> <iref primary="true" item="Header Fields" subitem="Loca tion"/>
<iref primary="true" item="Location header field"/> <iref primary="true" item="Location header field"/>
<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 relation ship is specific resource in relation to the response. The type of relation ship is
defined by the combination of request method and status code semant ics. defined by the combination of request method and status code semant ics.
</t> </t>
<iref primary="true" item="Grammar" subitem="Location"/ > <iref primary="true" item="Grammar" subitem="Location"/ >
<sourcecode type="abnf7230"><![CDATA[ Location = URI-r eference <sourcecode type="abnf9110"><![CDATA[ Location = URI-r eference
]]></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="URI" sectionFormat="comma" s ection="4.2"/>), of a relative reference (<xref target="URI" sectionFormat="comma" s ection="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="URI" 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> re sponses, the Location value refers to For <xref target="status.201" format="none">201 (Created)</xref> re sponses, the Location value refers to
the primary resource created by the request. the primary resource created by the request.
skipping to change at line 5793 skipping to change at line 5790
how long the service is expected to be unavailable to the client. how long the service is expected to be unavailable to the client.
When sent with any <xref target="status.3xx" format="none">3xx (Red irection)</xref> response, Retry-After When sent with any <xref target="status.3xx" format="none">3xx (Red irection)</xref> response, Retry-After
indicates the minimum time that the user agent is asked to wait bef ore indicates the minimum time that the user agent is asked to wait bef ore
issuing the redirected request. issuing the redirected request.
</t> </t>
<t> <t>
The Retry-After field value can be either an HTTP-date or a number The Retry-After field value can be either an HTTP-date or a number
of seconds to delay after receiving the response. of seconds to delay after receiving the response.
</t> </t>
<iref primary="true" item="Grammar" subitem="Retry-Afte r"/> <iref primary="true" item="Grammar" subitem="Retry-Afte r"/>
<sourcecode type="abnf7230"><![CDATA[ Retry-After = HT TP-date / delay-seconds <sourcecode type="abnf9110"><![CDATA[ Retry-After = HT TP-date / delay-seconds
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.delay-seconds"> <t anchor="rule.delay-seconds">
A delay-seconds value is a non-negative decimal integer, representi ng time A delay-seconds value is a non-negative decimal integer, representi ng time
in seconds. in seconds.
</t> </t>
<iref primary="true" item="Grammar" subitem="delay-seco nds"/> <iref primary="true" item="Grammar" subitem="delay-seco nds"/>
<sourcecode type="abnf7230"><![CDATA[ delay-seconds = 1*DIGIT <sourcecode type="abnf9110"><![CDATA[ delay-seconds = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
Two examples of its use are Two examples of its use are
</t> </t>
<sourcecode type="http-message"><![CDATA[Retry-After: F ri, 31 Dec 1999 23:59:59 GMT <sourcecode type="http-message"><![CDATA[Retry-After: F ri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
]]></sourcecode> ]]></sourcecode>
<t> <t>
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
</t> </t>
skipping to change at line 5826 skipping to change at line 5823
<iref primary="true" item="Server header field"/> <iref primary="true" item="Server header field"/>
<t> <t>
The "Server" header field contains information about the The "Server" header field contains information about the
software used by the origin server to handle the request, which is often software used by the origin server to handle the request, which is often
used by clients to help identify the scope of reported interoperabi lity used by clients to help identify the scope of reported interoperabi lity
problems, to work around or tailor requests to avoid particular ser ver problems, to work around or tailor requests to avoid particular ser ver
limitations, and for analytics regarding server or operating system use. limitations, and for analytics regarding server or operating system use.
An origin server <bcp14>MAY</bcp14> generate a Server header field in its responses. An origin server <bcp14>MAY</bcp14> generate a Server header field in its responses.
</t> </t>
<iref primary="true" item="Grammar" subitem="Server"/> <iref primary="true" item="Grammar" subitem="Server"/>
<sourcecode type="abnf7230"><![CDATA[ Server = product *( RWS ( product / comment ) ) <sourcecode type="abnf9110"><![CDATA[ Server = product *( RWS ( product / comment ) )
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Server header field value consists of one or more product ident ifiers, each The Server header field value consists of one or more product ident ifiers, each
followed by zero or more comments (<xref target="comments"/>), whic h together followed by zero or more comments (<xref target="comments"/>), whic h together
identify the origin server software and its significant subproducts . identify the origin server software and its significant subproducts .
By convention, the product identifiers are listed in decreasing ord er of By convention, the product identifiers are listed in decreasing ord er of
their significance for identifying the origin server software. Each product their significance for identifying the origin server software. Each product
identifier consists of a name and optional version, as defined in identifier consists of a name and optional version, as defined in
<xref target="field.user-agent"/>. <xref target="field.user-agent"/>.
</t> </t>
skipping to change at line 5863 skipping to change at line 5860
<section anchor="authentication" title="HTTP Authentication"> <section anchor="authentication" title="HTTP Authentication">
<section anchor="auth.scheme" title="Authentication Scheme"> <section anchor="auth.scheme" title="Authentication Scheme">
<t> <t>
HTTP provides a general framework for access control and authentica tion, HTTP provides a general framework for access control and authentica tion,
via an extensible set of challenge-response authentication schemes, which via an extensible set of challenge-response authentication schemes, which
can be used by a server to challenge a client request and by a clie nt to can be used by a server to challenge a client request and by a clie nt to
provide authentication information. It uses a case-insensitive provide authentication information. It uses a case-insensitive
token to identify the authentication scheme: token to identify the authentication scheme:
</t> </t>
<iref primary="true" item="Grammar" subitem="auth-scheme"/ > <iref primary="true" item="Grammar" subitem="auth-scheme"/ >
<sourcecode type="abnf7230"><![CDATA[ auth-scheme = to ken <sourcecode type="abnf9110"><![CDATA[ auth-scheme = to ken
]]></sourcecode> ]]></sourcecode>
<t> <t>
Aside from the general framework, this document does not specify an y Aside from the general framework, this document does not specify an y
authentication schemes. New and existing authentication schemes are authentication schemes. New and existing authentication schemes are
specified independently and ought to be registered within the specified independently and ought to be registered within the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" . "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" .
For example, the "basic" and "digest" authentication schemes are de fined by For example, the "basic" and "digest" authentication schemes are de fined by
<xref target="RFC7617">RFC 7617</xref> and <xref target="RFC7617">RFC 7617</xref> and
<xref target="RFC7616">RFC 7616</xref>, respectively. <xref target="RFC7616">RFC 7616</xref>, respectively.
</t> </t>
</section> </section>
<section anchor="auth.params" title="Authentication Parameter s"> <section anchor="auth.params" title="Authentication Parameter s">
<t> <t>
The authentication scheme is followed by additional information nec essary The authentication scheme is followed by additional information nec essary
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 characte rs comma-separated list of parameters or a single sequence of characte rs
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="abnf9110"><![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="URI"/>, 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 base 16 (hex) base64, base64url (URL and filename safe alphabet), base32, or base 16 (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 toke n is Authentication parameters are name=value pairs, where the name toke n is
matched case-insensitively matched case-insensitively
and each parameter name <bcp14>MUST</bcp14> only occur once per cha llenge. and each parameter name <bcp14>MUST</bcp14> only occur once per cha llenge.
</t> </t>
<iref primary="true" item="Grammar" subitem="auth-param"/> <iref primary="true" item="Grammar" subitem="auth-param"/>
<sourcecode type="abnf7230"><![CDATA[ auth-param = to ken BWS "=" BWS ( token / quoted-string ) <sourcecode type="abnf9110"><![CDATA[ auth-param = to ken BWS "=" BWS ( token / quoted-string )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Parameter values can be expressed either as "token" or as "quoted-s tring" Parameter values can be expressed either as "token" or as "quoted-s tring"
(<xref target="fields.components"/>). (<xref target="fields.components"/>).
Authentication scheme definitions need to accept both notations, bo th for Authentication scheme definitions need to accept both notations, bo th for
senders and recipients, to allow recipients to use generic parsing senders and recipients, to allow recipients to use generic parsing
components regardless of the authentication scheme. components regardless of the authentication scheme.
</t> </t>
<t> <t>
For backwards compatibility, authentication scheme definitions can restrict For backwards compatibility, authentication scheme definitions can restrict
skipping to change at line 5929 skipping to change at line 5926
<xref target="field.www-authenticate" format="none">WWW-Authenticat e</xref> header field containing at least one <xref target="field.www-authenticate" format="none">WWW-Authenticat e</xref> header field containing at least one
challenge applicable to the requested resource. challenge applicable to the requested resource.
</t> </t>
<t> <t>
A <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref> response message is A <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref> response message is
used by a proxy to challenge the authorization of a client, includi ng a used by a proxy to challenge the authorization of a client, includi ng a
<xref target="field.proxy-authenticate" format="none">Proxy-Authent icate</xref> header field containing at least one <xref target="field.proxy-authenticate" format="none">Proxy-Authent icate</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="abnf7230"><![CDATA[ challenge = auth- scheme [ 1*SP ( token68 / #auth-param ) ] <sourcecode type="abnf9110"><![CDATA[ challenge = auth- scheme [ 1*SP ( token68 / #auth-param ) ]
]]></sourcecode> ]]></sourcecode>
<aside> <aside>
<t> <t>
<strong>Note:</strong> Many clients fail to parse a challenge that contains an unknown <strong>Note:</strong> Many clients fail to parse a challenge that contains an unknown
scheme. A workaround for this problem is to list well-supported s chemes scheme. A workaround for this problem is to list well-supported s chemes
(such as "basic") first.<!-- [auth] see https://greenbytes.de/tec h/tc/httpauth/#multibasicunknown2 --> (such as "basic") first.<!-- [auth] see https://greenbytes.de/tec h/tc/httpauth/#multibasicunknown2 -->
</t> </t>
</aside> </aside>
<t> <t>
A user agent that wishes to authenticate itself with an origin serv er A user agent that wishes to authenticate itself with an origin serv er
skipping to change at line 5967 skipping to change at line 5964
challenge received in a response (possibly at some point in the pas t). challenge received in a response (possibly at some point in the pas t).
When creating their values, the user agent ought to do so by select ing the When creating their values, the user agent ought to do so by select ing the
challenge with what it considers to be the most secure auth-scheme that it challenge with what it considers to be the most secure auth-scheme that it
understands, obtaining credentials from the user as appropriate. understands, obtaining credentials from the user as appropriate.
Transmission of credentials within header field values implies sign ificant Transmission of credentials within header field values implies sign ificant
security considerations regarding the confidentiality of the underl ying security considerations regarding the confidentiality of the underl ying
connection, as described in connection, as described in
<xref target="confidentiality.of.credentials"/>. <xref target="confidentiality.of.credentials"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="credentials"/ > <iref primary="true" item="Grammar" subitem="credentials"/ >
<sourcecode type="abnf7230"><![CDATA[ credentials = auth- scheme [ 1*SP ( token68 / #auth-param ) ] <sourcecode type="abnf9110"><![CDATA[ credentials = auth- scheme [ 1*SP ( token68 / #auth-param ) ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
Upon receipt of a request for a protected resource that omits crede ntials, Upon receipt of a request for a protected resource that omits crede ntials,
contains invalid credentials (e.g., a bad password) or partial cred entials contains invalid credentials (e.g., a bad password) or partial cred entials
(e.g., when the authentication scheme requires more than one round trip), (e.g., when the authentication scheme requires more than one round trip),
an origin server <bcp14>SHOULD</bcp14> send a <xref target="status. 401" format="none">401 (Unauthorized)</xref> response an origin server <bcp14>SHOULD</bcp14> send a <xref target="status. 401" format="none">401 (Unauthorized)</xref> response
that contains a <xref target="field.www-authenticate" format="none" >WWW-Authenticate</xref> header field with at least that contains a <xref target="field.www-authenticate" format="none" >WWW-Authenticate</xref> header field with at least
one (possibly new) challenge applicable to the requested resource. one (possibly new) challenge applicable to the requested resource.
</t> </t>
<t> <t>
skipping to change at line 6062 skipping to change at line 6059
title="Authenticating Users to Origin Servers"> title="Authenticating Users to Origin Servers">
<section anchor="field.www-authenticate" title="WWW-Authen ticate"> <section anchor="field.www-authenticate" title="WWW-Authen ticate">
<iref primary="true" item="Fields" subitem="WWW-Authent icate"/> <iref primary="true" item="Fields" subitem="WWW-Authent icate"/>
<iref primary="true" item="Header Fields" subitem="WWW- Authenticate"/> <iref primary="true" item="Header Fields" subitem="WWW- Authenticate"/>
<iref primary="true" item="WWW-Authenticate header fiel d"/> <iref primary="true" item="WWW-Authenticate header fiel d"/>
<t> <t>
The "WWW-Authenticate" response header field indicates the authenti cation The "WWW-Authenticate" response header field indicates the authenti cation
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="WWW-Authen ticate"/> <iref primary="true" item="Grammar" subitem="WWW-Authen ticate"/>
<sourcecode type="abnf7230"><![CDATA[ WWW-Authenticate = #challenge <sourcecode type="abnf9110"><![CDATA[ WWW-Authenticate = #challenge
]]></sourcecode> ]]></sourcecode>
<t> <t>
A server generating a <xref target="status.401" format="none">401 ( Unauthorized)</xref> response A server generating a <xref target="status.401" format="none">401 ( Unauthorized)</xref> response
<bcp14>MUST</bcp14> send a WWW-Authenticate header field containing at least one <bcp14>MUST</bcp14> send a WWW-Authenticate header field containing at least one
challenge. A server <bcp14>MAY</bcp14> generate a WWW-Authenticate header field challenge. A server <bcp14>MAY</bcp14> generate a WWW-Authenticate header field
in other response messages to indicate that supplying credentials in other response messages to indicate that supplying credentials
(or different credentials) might affect the response. (or different credentials) might affect the response.
</t> </t>
<t> <t>
A proxy forwarding a response <bcp14>MUST NOT</bcp14> modify any A proxy forwarding a response <bcp14>MUST NOT</bcp14> modify any
skipping to change at line 6120 skipping to change at line 6117
<iref primary="true" item="Header Fields" subitem="Auth orization"/> <iref primary="true" item="Header Fields" subitem="Auth orization"/>
<iref primary="true" item="Authorization header field"/ > <iref primary="true" item="Authorization header field"/ >
<t> <t>
The "Authorization" header field allows a user agent to authenticat e itself The "Authorization" header field allows a user agent to authenticat e itself
with an origin server -- usually, but not necessarily, after receiv ing with an origin server -- usually, but not necessarily, after receiv ing
a <xref target="status.401" format="none">401 (Unauthorized)</xref> response. Its value consists of a <xref target="status.401" format="none">401 (Unauthorized)</xref> response. Its value consists of
credentials containing the authentication information of the user a gent for credentials containing the authentication information of the user a gent for
the realm of the resource being requested. the realm of the resource being requested.
</t> </t>
<iref primary="true" item="Grammar" subitem="Authorizat ion"/> <iref primary="true" item="Grammar" subitem="Authorizat ion"/>
<sourcecode type="abnf7230"><![CDATA[ Authorization = credentials <sourcecode type="abnf9110"><![CDATA[ Authorization = credentials
]]></sourcecode> ]]></sourcecode>
<t> <t>
If a request is authenticated and a realm specified, the same crede ntials If a request is authenticated and a realm specified, the same crede ntials
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, s uch as that the authentication scheme itself does not require otherwise, s uch as
credentials that vary according to a challenge value or using synch ronized credentials that vary according to a challenge value or using synch ronized
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
skipping to change at line 6155 skipping to change at line 6152
</t> </t>
<t> <t>
The field value is a list of parameters (name/value pairs), using t he "auth-param" The field value is a list of parameters (name/value pairs), using t he "auth-param"
syntax defined in <xref target="challenge.and.response"/>. syntax defined in <xref target="challenge.and.response"/>.
This specification only describes the generic format; authenticatio n schemes This specification only describes the generic format; authenticatio n schemes
using Authentication-Info will define the individual parameters. Th e "Digest" using Authentication-Info will define the individual parameters. Th e "Digest"
Authentication Scheme, for instance, defines multiple parameters in Authentication Scheme, for instance, defines multiple parameters in
<xref target="RFC7616" section="3.5"/>. <xref target="RFC7616" section="3.5"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Authentica tion-Info"/> <iref primary="true" item="Grammar" subitem="Authentica tion-Info"/>
<sourcecode type="abnf7230"><![CDATA[ Authentication-I nfo = #auth-param <sourcecode type="abnf9110"><![CDATA[ Authentication-I nfo = #auth-param
]]></sourcecode> ]]></sourcecode>
<t> <t>
The Authentication-Info field can be used in any HTTP response, The Authentication-Info field can be used in any HTTP response,
independently of request method and status code. Its semantics are defined independently of request method and status code. Its semantics are defined
by the authentication scheme indicated by the <xref target="field.a uthorization" format="none">Authorization</xref> header field by the authentication scheme indicated by the <xref target="field.a uthorization" format="none">Authorization</xref> header field
(<xref target="field.authorization"/>) of the corresponding request . (<xref target="field.authorization"/>) of the corresponding request .
</t> </t>
<t> <t>
A proxy forwarding a response is not allowed to modify the field va lue in any A proxy forwarding a response is not allowed to modify the field va lue in any
way. way.
skipping to change at line 6188 skipping to change at line 6185
<iref primary="true" item="Proxy-Authenticate header fi eld"/> <iref primary="true" item="Proxy-Authenticate header fi eld"/>
<t> <t>
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameter s challenge that indicates the authentication scheme(s) and parameter s
applicable to the proxy for this request. applicable to the proxy for this request.
A proxy <bcp14>MUST</bcp14> send at least one Proxy-Authenticate he ader field in A proxy <bcp14>MUST</bcp14> send at least one Proxy-Authenticate he ader field in
each <xref target="status.407" format="none">407 (Proxy Authenticat ion Required)</xref> response that it each <xref target="status.407" format="none">407 (Proxy Authenticat ion Required)</xref> response that it
generates. generates.
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Auth enticate"/> <iref primary="true" item="Grammar" subitem="Proxy-Auth enticate"/>
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authentica te = #challenge <sourcecode type="abnf9110"><![CDATA[ Proxy-Authentica te = #challenge
]]></sourcecode> ]]></sourcecode>
<t> <t>
Unlike <xref target="field.www-authenticate" format="none">WWW-Auth enticate</xref>, the Proxy-Authenticate header field Unlike <xref target="field.www-authenticate" format="none">WWW-Auth enticate</xref>, the Proxy-Authenticate header field
applies only to the next outbound client on the response chain. applies only to the next outbound client on the response chain.
This is because only the client that chose a given proxy is likely to have This is because only the client that chose a given proxy is likely to have
the credentials necessary for authentication. However, when multip le the credentials necessary for authentication. However, when multip le
proxies are used within the same administrative domain, such as off ice and proxies are used within the same administrative domain, such as off ice and
regional caching proxies within a large corporate network, it is co mmon regional caching proxies within a large corporate network, it is co mmon
for credentials to be generated by the user agent and passed throug h the for credentials to be generated by the user agent and passed throug h the
hierarchy until consumed. Hence, in such a configuration, it will appear hierarchy until consumed. Hence, in such a configuration, it will appear
skipping to change at line 6220 skipping to change at line 6217
<iref primary="true" item="Header Fields" subitem="Prox y-Authorization"/> <iref primary="true" item="Header Fields" subitem="Prox y-Authorization"/>
<iref primary="true" item="Proxy-Authorization header f ield"/> <iref primary="true" item="Proxy-Authorization header f ield"/>
<t> <t>
The "Proxy-Authorization" header field allows the client to The "Proxy-Authorization" header field allows the client to
identify itself (or its user) to a proxy that requires identify itself (or its user) to a proxy that requires
authentication. Its value consists of credentials containing the authentication. Its value consists of credentials containing the
authentication information of the client for the proxy and/or realm of the authentication information of the client for the proxy and/or realm of the
resource being requested. resource being requested.
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Auth orization"/> <iref primary="true" item="Grammar" subitem="Proxy-Auth orization"/>
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authorizat ion = credentials <sourcecode type="abnf9110"><![CDATA[ Proxy-Authorizat ion = credentials
]]></sourcecode> ]]></sourcecode>
<t> <t>
Unlike <xref target="field.authorization" format="none">Authorizati on</xref>, the Proxy-Authorization header field Unlike <xref target="field.authorization" format="none">Authorizati on</xref>, the Proxy-Authorization header field
applies only to the next inbound proxy that demanded authentication using applies only to the next inbound proxy that demanded authentication using
the <xref target="field.proxy-authenticate" format="none">Proxy-Aut henticate</xref> header field. When multiple proxies are used the <xref target="field.proxy-authenticate" format="none">Proxy-Aut henticate</xref> header field. When multiple proxies are used
in a chain, the Proxy-Authorization header field is consumed by the first in a chain, the Proxy-Authorization header field is consumed by the first
inbound proxy that was expecting to receive credentials. A proxy <b cp14>MAY</bcp14> inbound proxy that was expecting to receive credentials. A proxy <b cp14>MAY</bcp14>
relay the credentials from the client request to the next proxy if that is relay the credentials from the client request to the next proxy if that is
the mechanism by which the proxies cooperatively authenticate a giv en the mechanism by which the proxies cooperatively authenticate a giv en
request. request.
skipping to change at line 6249 skipping to change at line 6246
<iref primary="true" item="Proxy-Authentication-Info he ader field"/> <iref primary="true" item="Proxy-Authentication-Info he ader field"/>
<t> <t>
The "Proxy-Authentication-Info" response header field is equivalent to The "Proxy-Authentication-Info" response header field is equivalent to
<xref target="field.authentication-info" format="none">Authenticati on-Info</xref>, except that it applies to proxy authentication (<xref target="challenge.and.response"/>) <xref target="field.authentication-info" format="none">Authenticati on-Info</xref>, except that it applies to proxy authentication (<xref target="challenge.and.response"/>)
and its semantics are defined by the and its semantics are defined by the
authentication scheme indicated by the Proxy-Authorization header f ield authentication scheme indicated by the Proxy-Authorization header f ield
(<xref target="field.proxy-authorization"/>) (<xref target="field.proxy-authorization"/>)
of the corresponding request: of the corresponding request:
</t> </t>
<iref primary="true" item="Grammar" subitem="Proxy-Auth entication-Info"/> <iref primary="true" item="Grammar" subitem="Proxy-Auth entication-Info"/>
<sourcecode type="abnf7230"><![CDATA[ Proxy-Authentica tion-Info = #auth-param <sourcecode type="abnf9110"><![CDATA[ Proxy-Authentica tion-Info = #auth-param
]]></sourcecode> ]]></sourcecode>
<t> <t>
However, unlike <xref target="field.authentication-info" format="no ne">Authentication-Info</xref>, the Proxy-Authentication-Info header However, unlike <xref target="field.authentication-info" format="no ne">Authentication-Info</xref>, the Proxy-Authentication-Info header
field applies only to the next outbound client on the response chai n. This is field applies only to the next outbound client on the response chai n. This is
because only the client that chose a given proxy is likely to have the because only the client that chose a given proxy is likely to have the
credentials necessary for authentication. However, when multiple pr oxies are credentials necessary for authentication. However, when multiple pr oxies are
used within the same administrative domain, such as office and regi onal used within the same administrative domain, such as office and regi onal
caching proxies within a large corporate network, it is common for caching proxies within a large corporate network, it is common for
credentials to be generated by the user agent and passed through th e credentials to be generated by the user agent and passed through th e
hierarchy until consumed. Hence, in such a configuration, it will a ppear as hierarchy until consumed. Hence, in such a configuration, it will a ppear as
skipping to change at line 6485 skipping to change at line 6482
that can be selected for a resource. that can be selected for a resource.
</t> </t>
<t> <t>
The weight is normalized to a real number in the range 0 through 1, The weight is normalized to a real number in the range 0 through 1,
where 0.001 is the least preferred and 1 is the most preferred; where 0.001 is the least preferred and 1 is the most preferred;
a value of 0 means "not acceptable". If no "q" parameter is present , a value of 0 means "not acceptable". If no "q" parameter is present ,
the default weight is 1. the default weight is 1.
</t> </t>
<iref primary="true" item="Grammar" subitem="weight"/> <iref primary="true" item="Grammar" subitem="weight"/>
<iref primary="true" item="Grammar" subitem="qvalue"/> <iref primary="true" item="Grammar" subitem="qvalue"/>
<sourcecode type="abnf7230"><![CDATA[ weight = OWS ";" OWS "q=" qvalue <sourcecode type="abnf9110"><![CDATA[ weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] ) / ( "1" [ "." 0*3("0") ] )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A sender of qvalue <bcp14>MUST NOT</bcp14> generate more than three digits after the A sender of qvalue <bcp14>MUST NOT</bcp14> generate more than three digits after the
decimal point. User configuration of these values ought to be limit ed in decimal point. User configuration of these values ought to be limit ed in
the same fashion. the same fashion.
</t> </t>
</section> </section>
<section anchor="wildcard.values" title="Wildcard Values"> <section anchor="wildcard.values" title="Wildcard Values">
skipping to change at line 6535 skipping to change at line 6532
a small set of desired types, as in the case of a request for an in -line a small set of desired types, as in the case of a request for an in -line
image. image.
</t> </t>
<t> <t>
When sent by a server in a response, Accept provides information When sent by a server in a response, Accept provides information
about which content types are preferred in the content of a subsequ ent about which content types are preferred in the content of a subsequ ent
request to the same resource. request to the same resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept"/> <iref primary="true" item="Grammar" subitem="Accept"/>
<iref primary="true" item="Grammar" subitem="media-rang e"/> <iref primary="true" item="Grammar" subitem="media-rang e"/>
<sourcecode type="abnf7230"><![CDATA[ Accept = #( medi a-range [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept = #( medi a-range [ weight ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) parameters ) parameters
]]></sourcecode> ]]></sourcecode>
<t> <t>
The asterisk "*" character is used to group media types into ranges , The asterisk "*" character is used to group media types into ranges ,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
skipping to change at line 6672 skipping to change at line 6669
<iref primary="true" item="Header Fields" subitem="Acce pt-Charset"/> <iref primary="true" item="Header Fields" subitem="Acce pt-Charset"/>
<iref primary="true" item="Accept-Charset header field" /> <iref primary="true" item="Accept-Charset header field" />
<t> <t>
The "Accept-Charset" header field can be sent by a user agent to in dicate The "Accept-Charset" header field can be sent by a user agent to in dicate
its preferences for charsets in textual response content. For examp le, its preferences for charsets in textual response content. For examp le,
this field allows user agents capable of understanding more compreh ensive this field allows user agents capable of understanding more compreh ensive
or special-purpose charsets to signal that capability to an origin server or special-purpose charsets to signal that capability to an origin server
that is capable of representing information in those charsets. that is capable of representing information in those charsets.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Cha rset"/> <iref primary="true" item="Grammar" subitem="Accept-Cha rset"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Charset = #( ( token / "*" ) [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Charset = #( ( token / "*" ) [ weight ] )
]]></sourcecode> ]]></sourcecode>
<t> <t>
Charset names are defined in <xref target="charset"/>. Charset names are defined in <xref target="charset"/>.
A user agent <bcp14>MAY</bcp14> associate a quality value with each charset to indicate A user agent <bcp14>MAY</bcp14> associate a quality value with each charset to indicate
the user's relative preference for that charset, as defined in <xre f target="quality.values"/>. the user's relative preference for that charset, as defined in <xre f target="quality.values"/>.
An example is An example is
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Charset : iso-8859-5, unicode-1-1;q=0.8 <sourcecode type="http-message"><![CDATA[Accept-Charset : iso-8859-5, unicode-1-1;q=0.8
]]></sourcecode> ]]></sourcecode>
<t> <t>
skipping to change at line 6720 skipping to change at line 6717
When sent by a server in a response, Accept-Encoding provides infor mation When sent by a server in a response, Accept-Encoding provides infor mation
about which content codings are preferred in the content of a subse quent about which content codings are preferred in the content of a subse quent
request to the same resource. request to the same resource.
</t> </t>
<t> <t>
An "identity" token is used as a synonym for An "identity" token is used as a synonym for
"no encoding" in order to communicate when no encoding is preferred . "no encoding" in order to communicate when no encoding is preferred .
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Enc oding"/> <iref primary="true" item="Grammar" subitem="Accept-Enc oding"/>
<iref primary="true" item="Grammar" subitem="codings"/> <iref primary="true" item="Grammar" subitem="codings"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Encoding = #( codings [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each codings value <bcp14>MAY</bcp14> be given an associated qualit y value (weight) Each codings value <bcp14>MAY</bcp14> be given an associated qualit y value (weight)
representing the preference for that encoding, as defined in <xref target="quality.values"/>. representing the preference for that encoding, as defined in <xref target="quality.values"/>.
The asterisk "*" symbol in an Accept-Encoding field matches any ava ilable The asterisk "*" symbol in an Accept-Encoding field matches any ava ilable
content coding not explicitly listed in the field. content coding not explicitly listed in the field.
</t> </t>
<t> <t>
Examples: Examples:
skipping to change at line 6812 skipping to change at line 6809
<iref primary="true" item="Fields" subitem="Accept-Lang uage"/> <iref primary="true" item="Fields" subitem="Accept-Lang uage"/>
<iref primary="true" item="Header Fields" subitem="Acce pt-Language"/> <iref primary="true" item="Header Fields" subitem="Acce pt-Language"/>
<iref primary="true" item="Accept-Language header field "/> <iref primary="true" item="Accept-Language header field "/>
<t> <t>
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the res ponse. indicate the set of natural languages that are preferred in the res ponse.
Language tags are defined in <xref target="language.tags"/>. Language tags are defined in <xref target="language.tags"/>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Lan guage"/> <iref primary="true" item="Grammar" subitem="Accept-Lan guage"/>
<iref primary="true" item="Grammar" subitem="language-r ange"/> <iref primary="true" item="Grammar" subitem="language-r ange"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Language = #( language-range [ weight ] ) <sourcecode type="abnf9110"><![CDATA[ Accept-Language = #( language-range [ weight ] )
language-range = language-range =
<language-range, see [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
]]></sourcecode> ]]></sourcecode>
<t> <t>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in <xref target="quality.values "/>. For example, specified by that range, as defined in <xref target="quality.values "/>. For example,
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Languag e: da, en-gb;q=0.8, en;q=0.7 <sourcecode type="http-message"><![CDATA[Accept-Languag e: da, en-gb;q=0.8, en;q=0.7
]]></sourcecode> ]]></sourcecode>
skipping to change at line 6879 skipping to change at line 6876
<section anchor="field.vary" title="Vary"> <section anchor="field.vary" title="Vary">
<iref primary="true" item="Fields" subitem="Vary"/> <iref primary="true" item="Fields" subitem="Vary"/>
<iref primary="true" item="Header Fields" subitem="Vary "/> <iref primary="true" item="Header Fields" subitem="Vary "/>
<iref item="Vary header field" primary="true"/> <iref item="Vary header field" primary="true"/>
<t> <t>
The "Vary" header field in a response describes what parts of a req uest The "Vary" header field in a response describes what parts of a req uest
message, aside from the method and target URI, might have influence d the message, aside from the method and target URI, might have influence d the
origin server's process for selecting the content of this response. origin server's process for selecting the content of this response.
</t> </t>
<iref primary="true" item="Grammar" subitem="Vary"/> <iref primary="true" item="Grammar" subitem="Vary"/>
<sourcecode type="abnf7230"><![CDATA[ Vary = #( "*" / field-name ) <sourcecode type="abnf9110"><![CDATA[ Vary = #( "*" / field-name )
]]></sourcecode> ]]></sourcecode>
<t> <t>
A Vary field value is either the wildcard member "*" or a list of A Vary field value is either the wildcard member "*" or a list of
request field names, known as the selecting header fields, that mig ht request field names, known as the selecting header fields, that mig ht
have had a role in selecting the representation for this response. have had a role in selecting the representation for this response.
Potential selecting header fields are not limited to fields defined by Potential selecting header fields are not limited to fields defined by
this specification. this specification.
</t> </t>
<t> <t>
A list containing the member "*" signals that other aspects of the A list containing the member "*" signals that other aspects of the
skipping to change at line 7034 skipping to change at line 7031
entity-tag matching a member of the list of entity-tags provided in the entity-tag matching a member of the list of entity-tags provided in the
field value. field value.
</t> </t>
<t> <t>
An origin server <bcp14>MUST</bcp14> use the strong comparison func tion when comparing An origin server <bcp14>MUST</bcp14> use the strong comparison func tion when comparing
entity-tags for If-Match (<xref target="entity.tag.comparison"/>), since entity-tags for If-Match (<xref target="entity.tag.comparison"/>), since
the client intends this precondition to prevent the method from bei ng the client intends this precondition to prevent the method from bei ng
applied if there have been any changes to the representation data. applied if there have been any changes to the representation data.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Match"/ > <iref primary="true" item="Grammar" subitem="If-Match"/ >
<sourcecode type="abnf7230"><![CDATA[ If-Match = "*" / #entity-tag <sourcecode type="abnf9110"><![CDATA[ If-Match = "*" / #entity-tag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Examples: Examples:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Match: "xyz zy" <sourcecode type="http-message"><![CDATA[If-Match: "xyz zy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: * If-Match: *
]]></sourcecode> ]]></sourcecode>
<t> <t>
If-Match is most often used with state-changing methods (e.g., POST , PUT, If-Match is most often used with state-changing methods (e.g., POST , PUT,
skipping to change at line 7141 skipping to change at line 7138
having a <xref target="selected.representation" format="none">selec ted representation</xref> with an entity-tag that does not match any having a <xref target="selected.representation" format="none">selec ted representation</xref> with an entity-tag that does not match any
of those listed in the field value. of those listed in the field value.
</t> </t>
<t> <t>
A recipient <bcp14>MUST</bcp14> use the weak comparison function wh en comparing A recipient <bcp14>MUST</bcp14> use the weak comparison function wh en comparing
entity-tags for If-None-Match (<xref target="entity.tag.comparison" />), entity-tags for If-None-Match (<xref target="entity.tag.comparison" />),
since weak entity-tags can be used for cache validation even if the re have since weak entity-tags can be used for cache validation even if the re have
been changes to the representation data. been changes to the representation data.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-None-Ma tch"/> <iref primary="true" item="Grammar" subitem="If-None-Ma tch"/>
<sourcecode type="abnf7230"><![CDATA[ If-None-Match = "*" / #entity-tag <sourcecode type="abnf9110"><![CDATA[ If-None-Match = "*" / #entity-tag
]]></sourcecode> ]]></sourcecode>
<t> <t>
Examples: Examples:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-None-Match: "xyzzy" <sourcecode type="http-message"><![CDATA[If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: * If-None-Match: *
]]></sourcecode> ]]></sourcecode>
skipping to change at line 7224 skipping to change at line 7221
<iref primary="true" item="Header Fields" subitem="If-M odified-Since"/> <iref primary="true" item="Header Fields" subitem="If-M odified-Since"/>
<iref primary="true" item="If-Modified-Since header fie ld"/> <iref primary="true" item="If-Modified-Since header fie ld"/>
<t> <t>
The "If-Modified-Since" header field makes a GET or HEAD request me thod The "If-Modified-Since" header field makes a GET or HEAD request me thod
conditional on the <xref target="selected.representation" format="n one">selected representation</xref>'s modification conditional on the <xref target="selected.representation" format="n one">selected representation</xref>'s modification
date being more date being more
recent than the date provided in the field value. Transfer of the s elected recent than the date provided in the field value. Transfer of the s elected
representation's data is avoided if that data has not changed. representation's data is avoided if that data has not changed.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Modifie d-Since"/> <iref primary="true" item="Grammar" subitem="If-Modifie d-Since"/>
<sourcecode type="abnf7230"><![CDATA[ If-Modified-Sinc e = HTTP-date <sourcecode type="abnf9110"><![CDATA[ If-Modified-Sinc e = HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of the field is: An example of the field is:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Modified-Si nce: Sat, 29 Oct 1994 19:43:31 GMT <sourcecode type="http-message"><![CDATA[If-Modified-Si nce: Sat, 29 Oct 1994 19:43:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A recipient <bcp14>MUST</bcp14> ignore If-Modified-Since if the req uest contains an A recipient <bcp14>MUST</bcp14> ignore If-Modified-Since if the req uest contains an
<xref target="field.if-none-match" format="none">If-None-Match</xre f> header field; the condition in <xref target="field.if-none-match" format="none">If-None-Match</xre f> header field; the condition in
<xref target="field.if-none-match" format="none">If-None-Match</xre f> is considered to be a more accurate <xref target="field.if-none-match" format="none">If-None-Match</xre f> is considered to be a more accurate
skipping to change at line 7326 skipping to change at line 7323
<iref primary="true" item="If-Unmodified-Since header f ield"/> <iref primary="true" item="If-Unmodified-Since header f ield"/>
<t> <t>
The "If-Unmodified-Since" header field makes the request method con ditional The "If-Unmodified-Since" header field makes the request method con ditional
on the <xref target="selected.representation" format="none">selecte d representation</xref>'s last modification date being on the <xref target="selected.representation" format="none">selecte d representation</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.
This field accomplishes the This field accomplishes the
same purpose as <xref target="field.if-match" format="none">If-Matc h</xref> for cases where the user agent does same purpose as <xref target="field.if-match" format="none">If-Matc h</xref> for cases where the user agent does
not have an entity-tag for the representation. not have an entity-tag for the representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Unmodif ied-Since"/> <iref primary="true" item="Grammar" subitem="If-Unmodif ied-Since"/>
<sourcecode type="abnf7230"><![CDATA[ If-Unmodified-Si nce = HTTP-date <sourcecode type="abnf9110"><![CDATA[ If-Unmodified-Si nce = HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
An example of the field is: An example of the field is:
</t> </t>
<sourcecode type="http-message"><![CDATA[If-Unmodified- Since: Sat, 29 Oct 1994 19:43:31 GMT <sourcecode type="http-message"><![CDATA[If-Unmodified- Since: Sat, 29 Oct 1994 19:43:31 GMT
]]></sourcecode> ]]></sourcecode>
<t> <t>
A recipient <bcp14>MUST</bcp14> ignore If-Unmodified-Since if the r equest contains an A recipient <bcp14>MUST</bcp14> ignore If-Unmodified-Since if the r equest contains an
<xref target="field.if-match" format="none">If-Match</xref> header field; the condition in <xref target="field.if-match" format="none">If-Match</xref> header field; the condition in
<xref target="field.if-match" format="none">If-Match</xref> is cons idered to be a more accurate replacement for <xref target="field.if-match" format="none">If-Match</xref> is cons idered to be a more accurate replacement for
skipping to change at line 7449 skipping to change at line 7446
representation has been modified, the client would then have to mak e a representation has been modified, the client would then have to mak e a
second request to obtain the entire current representation. second request to obtain the entire current representation.
</t> </t>
<t> <t>
The "If-Range" header field allows a client to "short-circuit" the second The "If-Range" header field allows a client to "short-circuit" the second
request. Informally, its meaning is as follows: if the representati on is unchanged, request. Informally, its meaning is as follows: if the representati on is unchanged,
send me the part(s) that I am requesting in Range; otherwise, send me the send me the part(s) that I am requesting in Range; otherwise, send me the
entire representation. entire representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="If-Range"/ > <iref primary="true" item="Grammar" subitem="If-Range"/ >
<sourcecode type="abnf7230"><![CDATA[ If-Range = entit y-tag / HTTP-date <sourcecode type="abnf9110"><![CDATA[ If-Range = entit y-tag / HTTP-date
]]></sourcecode> ]]></sourcecode>
<t> <t>
A valid <xref target="field.etag" format="none">entity-tag</xref> c an be distinguished from a valid A valid <xref target="field.etag" format="none">entity-tag</xref> c an be distinguished from a valid
<xref target="http.date" format="none">HTTP-date</xref> by examinin g the first three characters for a <xref target="http.date" format="none">HTTP-date</xref> by examinin g the first three characters for a
DQUOTE. DQUOTE.
</t> </t>
<t> <t>
A client <bcp14>MUST NOT</bcp14> generate an If-Range header field in a request that A client <bcp14>MUST NOT</bcp14> generate an If-Range header field in a request that
does not contain a <xref target="field.range" format="none">Range</ xref> header field. does not contain a <xref target="field.range" format="none">Range</ xref> header field.
A server <bcp14>MUST</bcp14> ignore an If-Range header field receiv ed in a request that A server <bcp14>MUST</bcp14> ignore an If-Range header field receiv ed in a request that
skipping to change at line 7707 skipping to change at line 7704
This general notion of a <em>range unit</em> is used This general notion of a <em>range unit</em> is used
in the <xref target="field.accept-ranges" format="none">Accept-Rang es</xref> (<xref target="field.accept-ranges"/>) in the <xref target="field.accept-ranges" format="none">Accept-Rang es</xref> (<xref target="field.accept-ranges"/>)
response header field to advertise support for range requests, the response header field to advertise support for range requests, the
<xref target="field.range" format="none">Range</xref> (<xref target ="field.range"/>) request header field <xref target="field.range" format="none">Range</xref> (<xref target ="field.range"/>) request header field
to delineate the parts of a representation that are requested, and the to delineate the parts of a representation that are requested, and the
<xref target="field.content-range" format="none">Content-Range</xre f> (<xref target="field.content-range"/>) <xref target="field.content-range" format="none">Content-Range</xre f> (<xref target="field.content-range"/>)
header field to describe which part of a representation is being header field to describe which part of a representation is being
transferred. transferred.
</t> </t>
<iref primary="true" item="Grammar" subitem="range-unit"/> <iref primary="true" item="Grammar" subitem="range-unit"/>
<sourcecode type="abnf7230"><![CDATA[ range-unit = token <sourcecode type="abnf9110"><![CDATA[ range-unit = token
]]></sourcecode> ]]></sourcecode>
<t> <t>
All range unit names are case-insensitive and ought to be registere d All range unit names are case-insensitive and ought to be registere d
within the "HTTP Range Unit Registry", as defined in within the "HTTP Range Unit Registry", as defined in
<xref target="range.unit.registry"/>. <xref target="range.unit.registry"/>.
</t> </t>
<t> <t>
Range units are intended to be extensible, as described in Range units are intended to be extensible, as described in
<xref target="range.unit.extensibility"/>. <xref target="range.unit.extensibility"/>.
</t> </t>
skipping to change at line 7735 skipping to change at line 7732
<xref target="rule.other-range" format="none">other-range</xref> ar e allowed. <xref target="rule.other-range" format="none">other-range</xref> ar e allowed.
</t> </t>
<t anchor="rule.ranges-specifier"> <t anchor="rule.ranges-specifier">
A range request can specify a single range or a set A range request can specify a single range or a set
of ranges within a single representation. of ranges within a single representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="ranges-spe cifier"/> <iref primary="true" item="Grammar" subitem="ranges-spe cifier"/>
<iref primary="true" item="Grammar" subitem="range-set" /> <iref primary="true" item="Grammar" subitem="range-set" />
<iref primary="true" item="Grammar" subitem="range-spec "/> <iref primary="true" item="Grammar" subitem="range-spec "/>
<sourcecode type="abnf7230"><![CDATA[ ranges-specifier = range-unit "=" range-set <sourcecode type="abnf9110"><![CDATA[ ranges-specifier = range-unit "=" range-set
range-set = 1#range-spec range-set = 1#range-spec
range-spec = int-range range-spec = int-range
/ suffix-range / suffix-range
/ other-range / other-range
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.int-range"> <t anchor="rule.int-range">
An <xref target="rule.int-range" format="none">int-range</xref> is a range expressed as two non-negative An <xref target="rule.int-range" format="none">int-range</xref> is a range expressed as two non-negative
integers or as one non-negative integer through to the end of the integers or as one non-negative integer through to the end of the
representation data. representation data.
The range unit specifies what the integers mean (e.g., they might i ndicate The range unit specifies what the integers mean (e.g., they might i ndicate
unit offsets from the beginning, inclusive numbered parts, etc.). unit offsets from the beginning, inclusive numbered parts, etc.).
</t> </t>
<iref primary="true" item="Grammar" subitem="int-range" /> <iref primary="true" item="Grammar" subitem="int-range" />
<iref primary="true" item="Grammar" subitem="first-pos" /> <iref primary="true" item="Grammar" subitem="first-pos" />
<iref primary="true" item="Grammar" subitem="last-pos"/ > <iref primary="true" item="Grammar" subitem="last-pos"/ >
<sourcecode type="abnf7230"><![CDATA[ int-range = first-pos "-" [ last-pos ] <sourcecode type="abnf9110"><![CDATA[ int-range = first-pos "-" [ last-pos ]
first-pos = 1*DIGIT first-pos = 1*DIGIT
last-pos = 1*DIGIT last-pos = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
An <xref target="rule.int-range" format="none">int-range</xref> is invalid if the An <xref target="rule.int-range" format="none">int-range</xref> is invalid if the
<xref target="rule.int-range" format="none">last-pos</xref> value i s present and less than the <xref target="rule.int-range" format="none">last-pos</xref> value i s present and less than the
<xref target="rule.int-range" format="none">first-pos</xref>. <xref target="rule.int-range" format="none">first-pos</xref>.
</t> </t>
<t anchor="rule.suffix-range"> <t anchor="rule.suffix-range">
A <xref target="rule.suffix-range" format="none">suffix-range</xref > is a range expressed as a suffix of the A <xref target="rule.suffix-range" format="none">suffix-range</xref > is a range expressed as a suffix of the
representation data with the provided non-negative integer maximum length representation data with the provided non-negative integer maximum length
(in range units). In other words, the last N units of the represent ation (in range units). In other words, the last N units of the represent ation
data. data.
</t> </t>
<iref primary="true" item="Grammar" subitem="suffix-ran ge"/> <iref primary="true" item="Grammar" subitem="suffix-ran ge"/>
<iref primary="true" item="Grammar" subitem="suffix-len gth"/> <iref primary="true" item="Grammar" subitem="suffix-len gth"/>
<sourcecode type="abnf7230"><![CDATA[ suffix-range = "-" suffix-length <sourcecode type="abnf9110"><![CDATA[ suffix-range = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t anchor="rule.other-range"> <t anchor="rule.other-range">
To provide for extensibility, the <xref target="rule.other-range" f ormat="none">other-range</xref> rule is a To provide for extensibility, the <xref target="rule.other-range" f ormat="none">other-range</xref> rule is a
mostly unconstrained grammar that allows application-specific or fu ture mostly unconstrained grammar that allows application-specific or fu ture
range units to define additional range specifiers. range units to define additional range specifiers.
</t> </t>
<iref primary="true" item="Grammar" subitem="other-rang e"/> <iref primary="true" item="Grammar" subitem="other-rang e"/>
<sourcecode type="abnf7230"><![CDATA[ other-range = 1*( %x21-2B / %x2D-7E ) <sourcecode type="abnf9110"><![CDATA[ other-range = 1*( %x21-2B / %x2D-7E )
; 1*(VCHAR excluding comma) ; 1*(VCHAR excluding comma)
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="byte.ranges" title="Byte Ranges"> <section anchor="byte.ranges" title="Byte Ranges">
<t> <t>
The "bytes" range unit is used to express subranges of a representa tion The "bytes" range unit is used to express subranges of a representa tion
data's octet sequence. data's octet sequence.
Each byte range is expressed as an integer range at some offset, re lative Each byte range is expressed as an integer range at some offset, re lative
to either the beginning (<xref target="rule.int-range" format="none ">int-range</xref>) or end to either the beginning (<xref target="rule.int-range" format="none ">int-range</xref>) or end
(<xref target="rule.suffix-range" format="none">suffix-range</xref> ) of the representation data. (<xref target="rule.suffix-range" format="none">suffix-range</xref> ) of the representation data.
skipping to change at line 7906 skipping to change at line 7903
<iref primary="true" item="Fields" subitem="Range"/> <iref primary="true" item="Fields" subitem="Range"/>
<iref primary="true" item="Header Fields" subitem="Range"/ > <iref primary="true" item="Header Fields" subitem="Range"/ >
<iref primary="true" item="Range header field"/> <iref primary="true" item="Range header field"/>
<t> <t>
The "Range" header field on a GET request modifies the method seman tics to The "Range" header field on a GET request modifies the method seman tics to
request transfer of only one or more subranges of the request transfer of only one or more subranges of the
selected representation data (<xref target="representation.data"/>) , selected representation data (<xref target="representation.data"/>) ,
rather than the entire <xref target="selected.representation" forma t="none">selected representation</xref>. rather than the entire <xref target="selected.representation" forma t="none">selected representation</xref>.
</t> </t>
<iref primary="true" item="Grammar" subitem="Range"/> <iref primary="true" item="Grammar" subitem="Range"/>
<sourcecode type="abnf7230"><![CDATA[ Range = ranges-spec ifier <sourcecode type="abnf9110"><![CDATA[ Range = ranges-spec ifier
]]></sourcecode> ]]></sourcecode>
<t> <t>
A server <bcp14>MAY</bcp14> ignore the Range header field. However, origin servers and A server <bcp14>MAY</bcp14> ignore the Range header field. However, origin servers and
intermediate caches ought to support byte ranges when possible, sin ce they intermediate caches ought to support byte ranges when possible, sin ce they
support efficient recovery from partially failed transfers and part ial support efficient recovery from partially failed transfers and part ial
retrieval of large representations. retrieval of large representations.
</t> </t>
<t> <t>
A server <bcp14>MUST</bcp14> ignore a Range header field received w ith a request method A server <bcp14>MUST</bcp14> ignore a Range header field received w ith a request method
that is unrecognized or for which range handling is not defined. Fo r this that is unrecognized or for which range handling is not defined. Fo r this
skipping to change at line 7992 skipping to change at line 7989
<section anchor="field.accept-ranges" title="Accept-Ranges"> <section anchor="field.accept-ranges" title="Accept-Ranges">
<iref primary="true" item="Fields" subitem="Accept-Ranges" /> <iref primary="true" item="Fields" subitem="Accept-Ranges" />
<iref primary="true" item="Header Fields" subitem="Accept- Ranges"/> <iref primary="true" item="Header Fields" subitem="Accept- Ranges"/>
<iref primary="true" item="Accept-Ranges header field"/> <iref primary="true" item="Accept-Ranges header field"/>
<t> <t>
The "Accept-Ranges" field in a response indicates whether an upstre am The "Accept-Ranges" field in a response indicates whether an upstre am
server supports range requests for the target resource. server supports range requests for the target resource.
</t> </t>
<iref primary="true" item="Grammar" subitem="Accept-Ranges "/> <iref primary="true" item="Grammar" subitem="Accept-Ranges "/>
<iref primary="true" item="Grammar" subitem="acceptable-ra nges"/> <iref primary="true" item="Grammar" subitem="acceptable-ra nges"/>
<sourcecode type="abnf7230"><![CDATA[ Accept-Ranges = acceptable-ranges <sourcecode type="abnf9110"><![CDATA[ Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit acceptable-ranges = 1#range-unit
]]></sourcecode> ]]></sourcecode>
<t> <t>
For example, a server that supports For example, a server that supports
<xref target="byte.ranges">byte-range requests</xref> can send the field <xref target="byte.ranges">byte-range requests</xref> can send the field
</t> </t>
<sourcecode type="http-message"><![CDATA[Accept-Ranges: by tes <sourcecode type="http-message"><![CDATA[Accept-Ranges: by tes
]]></sourcecode> ]]></sourcecode>
<t> <t>
to indicate that it supports byte range requests for that target re source, to indicate that it supports byte range requests for that target re source,
skipping to change at line 8070 skipping to change at line 8067
each body part, and sent in <xref target="status.416" format="none" >416 (Range Not Satisfiable)</xref> each body part, and sent in <xref target="status.416" format="none" >416 (Range Not Satisfiable)</xref>
responses to provide information about the selected representation. responses to provide information about the selected representation.
</t> </t>
<iref primary="true" item="Grammar" subitem="Content-Range "/> <iref primary="true" item="Grammar" subitem="Content-Range "/>
<iref primary="true" item="Grammar" subitem="range-resp"/> <iref primary="true" item="Grammar" subitem="range-resp"/>
<iref primary="true" item="Grammar" subitem="incl-range"/> <iref primary="true" item="Grammar" subitem="incl-range"/>
<iref primary="true" item="Grammar" subitem="unsatisfied-r ange"/> <iref primary="true" item="Grammar" subitem="unsatisfied-r ange"/>
<iref primary="true" item="Grammar" subitem="complete-leng th"/> <iref primary="true" item="Grammar" subitem="complete-leng th"/>
<iref primary="false" item="Grammar" subitem="first-pos"/> <iref primary="false" item="Grammar" subitem="first-pos"/>
<iref primary="false" item="Grammar" subitem="last-pos"/> <iref primary="false" item="Grammar" subitem="last-pos"/>
<sourcecode type="abnf7230"><![CDATA[ Content-Range = range-unit SP <sourcecode type="abnf9110"><![CDATA[ Content-Range = range-unit SP
( range-resp / unsatisfied-range ) ( range-resp / unsatisfied-range )
range-resp = incl-range "/" ( complete-length / "*" ) range-resp = incl-range "/" ( complete-length / "*" )
incl-range = first-pos "-" last-pos incl-range = first-pos "-" last-pos
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT complete-length = 1*DIGIT
]]></sourcecode> ]]></sourcecode>
<t> <t>
If a <xref target="status.206" format="none">206 (Partial Content)< /xref> response contains a If a <xref target="status.206" format="none">206 (Partial Content)< /xref> response contains a
skipping to change at line 9805 skipping to change at line 9802
<!-- [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 extens ibility Additionally, specific versions of HTTP might have their own extens ibility
points, such as transfer-codings in HTTP/1.1 (<xref target="HTTP11" section="6.1"/>) and HTTP/2 points, such as transfer-codings in HTTP/1.1 (<xref target="HTTP11" section="6.1"/>) and HTTP/2
SETTINGS or frame types <xref target="HTTP2"/>. These extension poi nts are specific to the SETTINGS or frame types (<xref target="HTTP2"/>). These extension p oints are specific 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 o r a version-independent mechanism or extension point (like a method o r
header field) without explicitly being allowed by that protocol ele ment. For header field) without explicitly being allowed by that protocol ele ment. 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 10671 skipping to change at line 10668
<t> <t>
HTTP messages can be compressed in a number of ways, including usin g TLS HTTP messages can be compressed in a number of ways, including usin g 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 compressi on on The most effective mitigation for this risk is to disable compressi on on
sensitive data, or to strictly separate sensitive data from attacke r-controlled sensitive data, or to strictly separate sensitive data from attacke r-controlled
data so that they cannot share the same compression dictionary. Wit h data so that they cannot share the same compression dictionary. Wit h
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 ta rget="HPACK"/>. considered exploitable in limited use cases, such as HPACK (<xref t arget="HPACK"/>).
</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 re sources including both information provided by the user to interact with re sources
(e.g., the user's name, location, mail address, passwords, encrypti on (e.g., the user's name, location, mail address, passwords, encrypti on
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 10834 skipping to change at line 10831
<section anchor="fingerprinting" title="Browser Fingerprintin g"> <section anchor="fingerprinting" title="Browser Fingerprintin g">
<t> <t>
Browser fingerprinting is a set of techniques for identifying a spe cific Browser fingerprinting is a set of techniques for identifying a spe cific
user agent over time through its unique set of characteristics. The se user agent over time through its unique set of characteristics. The se
characteristics might include information related to how it uses th e underlying characteristics might include information related to how it uses th e underlying
transport protocol, transport protocol,
feature capabilities, and scripting environment, though of particul ar feature capabilities, and scripting environment, though of particul ar
interest here is the set of unique characteristics that might be interest here is the set of unique characteristics that might be
communicated via HTTP. Fingerprinting is considered a privacy conce rn communicated via HTTP. Fingerprinting is considered a privacy conce rn
because it enables tracking of a user agent's behavior over time because it enables tracking of a user agent's behavior over time
<xref target="Bujlow"/> without (<xref target="Bujlow"/>) without
the corresponding controls that the user might have over other form s of the corresponding controls that the user might have over other form s of
data collection (e.g., cookies). Many general-purpose user agents data collection (e.g., cookies). Many general-purpose user agents
(i.e., Web browsers) have taken steps to reduce their fingerprints. (i.e., Web browsers) have taken steps to reduce their fingerprints.
</t> </t>
<t> <t>
There are a number of request header fields that might reveal infor mation There are a number of request header fields that might reveal infor mation
to servers that is sufficiently unique to enable fingerprinting. to servers that is sufficiently unique to enable fingerprinting.
The <xref target="field.from" format="none">From</xref> header fiel d is the most obvious, though it is The <xref target="field.from" format="none">From</xref> header fiel d is the most obvious, though it is
expected that From will only be sent when self-identification is de sired by expected that From will only be sent when self-identification is de sired by
the user. Likewise, Cookie header fields are deliberately designed to the user. Likewise, Cookie header fields are deliberately designed to
skipping to change at line 11936 skipping to change at line 11933
<tr> <tr>
<td>compress</td> <td>compress</td>
<td>UNIX "compress" data format <xref target="Wel ch"/> <td>UNIX "compress" data format <xref target="Wel ch"/>
</td> </td>
<td> <td>
<xref target="compress.coding" format="counter "/> <xref target="compress.coding" format="counter "/>
</td> </td>
</tr> </tr>
<tr> <tr>
<td>deflate</td> <td>deflate</td>
<td>"deflate" compressed data <xref target="RFC19 <td>"deflate" compressed data (<xref target="RFC1
51"/> inside 951"/>) inside
the "zlib" data format <xref target="RFC1950"/> the "zlib" data format (<xref target="RFC1950"/>)
</td> </td>
<td> <td>
<xref target="deflate.coding" format="counter" /> <xref target="deflate.coding" format="counter" />
</td> </td>
</tr> </tr>
<tr> <tr>
<td>gzip</td> <td>gzip</td>
<td>GZIP file format <xref target="RFC1952"/> <td>GZIP file format <xref target="RFC1952"/>
</td> </td>
<td> <td>
skipping to change at line 12799 skipping to change at line 12796
remove field links in this section? remove field links in this section?
--> -->
<section anchor="changes.from.rfc.7230" title="Changes from R FC 7230"> <section anchor="changes.from.rfc.7230" title="Changes from R FC 7230">
<t> <t>
The sections introducing HTTP's design goals, history, architecture , The sections introducing HTTP's design goals, history, architecture ,
conformance criteria, protocol versioning, URIs, message routing, a nd conformance criteria, protocol versioning, URIs, message routing, a nd
header fields have been moved here. header fields have been moved here.
</t> </t>
<t> <t>
The requirement on semantic conformance has been replaced with perm ission to The requirement on semantic conformance has been replaced with perm ission to
ignore or work around implementation-specific failures ignore or work around implementation-specific failures.
(<xref target="requirements.notation"/>). (<xref target="requirements.notation"/>)
</t> </t>
<t> <t>
The description of an origin and authoritative access to origin ser vers has The description of an origin and authoritative access to origin ser vers has
been extended for both "http" and "https" URIs to account for alter native been extended for both "http" and "https" URIs to account for alter native
services and secured connections that are not necessarily based on TCP services and secured connections that are not necessarily based on TCP.
(Sections <xref target="http.uri" format="counter"/>, <xref target= "https.uri" format="counter"/>, (Sections <xref target="http.uri" format="counter"/>, <xref target= "https.uri" format="counter"/>,
<xref target="origin" format="counter"/>, and <xref target="routing .origin" format="counter"/>). <xref target="origin" format="counter"/>, and <xref target="routing .origin" format="counter"/>)
</t> </t>
<t> <t>
Explicit requirements have been added to check the target URI schem e's semantics Explicit requirements have been added to check the target URI schem e's semantics
and reject requests that don't meet any associated requirements and reject requests that don't meet any associated requirements.
(<xref target="routing.reject"/>). (<xref target="routing.reject"/>)
</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>
"Field value" now refers to the value after multiple field lines ar e combined "Field value" now refers to the value after multiple field lines ar e combined
with commas -- by far the most common use. To refer to a single hea der with commas -- by far the most common use. To refer to a single hea der
line's value, use "field line value" line's value, use "field line value".
(<xref target="header.fields"/>). (<xref target="header.fields"/>)
</t> </t>
<t> <t>
Trailer field semantics now transcend the specifics of chunked enco ding. Trailer field semantics now transcend the specifics of chunked enco ding.
The use of trailer fields has been further limited to allow generat ion The use of trailer fields has been further limited to allow generat ion
as a trailer field only when the sender knows the field defines tha t usage and as a trailer field only when the sender knows the field defines tha t usage and
to allow merging into the header section only if the recipient know s the to allow merging into the header section only if the recipient know s the
corresponding field definition permits and defines how to merge. In all corresponding field definition permits and defines how to merge. In all
other cases, implementations are encouraged either to store the tra iler other cases, implementations are encouraged either to store the tra iler
fields separately or to discard them instead of merging fields separately or to discard them instead of merging.
(<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 header field by origin servers has been made explicit to align with
proxy handling proxy handling.
(<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="URI"/> 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 R FC 7231"> <section anchor="changes.from.rfc.7231" title="Changes from R FC 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?
Current: Current:
Minimum URI lengths to be supported by implementations are now Minimum URI lengths to be supported by implementations are now
recommended (Section 3.1). recommended (Section 3.1).
--> -->
<t> <t>
Minimum URI lengths to be supported by implementations are now reco Minimum URI lengths to be supported by implementations are now reco
mmended mmended.
(<xref target="resources"/>). (<xref target="resources"/>)
</t> </t>
<t> <t>
The following have been clarified: CR and NUL in field values are t o be rejected or The following have been clarified: CR and NUL in field values are t o be rejected or
mapped to SP, and leading and trailing whitespaces need to be mapped to SP, and leading and trailing whitespaces need to be
stripped from field values before they are consumed stripped from field values before they are consumed.
(<xref target="fields.values"/>). (<xref target="fields.values"/>)
</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 defi ne the An abstract data type for HTTP messages has been introduced to defi ne the
components of a message and their semantics as an abstraction acros s components of a message and their semantics as an abstraction acros s
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="HTTP11"/>, 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 requ irements message is parsed. This makes it easier to distinguish between requ irements
on the content (what is conveyed) versus requirements on the messag ing on the content (what is conveyed) versus requirements on the messag ing
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.abstractio n"/>)
</t> </t>
<t> <t>
The terms "payload" and "payload body" have been replaced with "con tent", to better The terms "payload" and "payload body" have been replaced with "con tent", 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"/>)
</t> </t>
<t> <t>
The term "effective request URI" has been replaced with "target URI The term "effective request URI" has been replaced with "target URI
" ".
(<xref target="target.resource"/>). (<xref target="target.resource"/>)
</t> </t>
<t> <t>
Restrictions on client retries have been loosened to reflect implem entation Restrictions on client retries have been loosened to reflect implem entation
behavior behavior.
(<xref target="idempotent.methods"/>). (<xref target="idempotent.methods"/>)
</t> </t>
<t> <t>
The fact that request bodies on GET, HEAD, and DELETE are not inter The fact that request bodies on GET, HEAD, and DELETE are not inter
operable has been clarified operable has been clarified.
(Sections <xref target="GET" format="counter"/>, <xref target="HEAD (Sections <xref target="GET" format="counter"/>, <xref target="HEAD
" format="counter"/>, and <xref target="DELETE" format="counter"/>). " format="counter"/>, and <xref target="DELETE" format="counter"/>)
</t> </t>
<t> <t>
The use of the <xref target="field.content-range" format="none">Con tent-Range</xref> header field The use of the <xref target="field.content-range" format="none">Con tent-Range</xref> header field
(<xref target="field.content-range"/>) as a request modifier on PUT (<xref target="field.content-range"/>) as a request modifier on PUT
is allowed is allowed.
(<xref target="PUT"/>). (<xref target="PUT"/>)
</t> </t>
<t> <t>
A superfluous requirement about setting <xref target="field.content -length" format="none">Content-Length</xref> A superfluous requirement about setting <xref target="field.content -length" format="none">Content-Length</xref>
has been removed from the description of the OPTIONS method has been removed from the description of the OPTIONS method.
(<xref target="OPTIONS"/>). (<xref target="OPTIONS"/>)
</t> </t>
<t> <t>
The normative requirement to use the message/http media type in The normative requirement to use the message/http media type in
TRACE responses has been removed TRACE responses has been removed.
(<xref target="TRACE"/>). (<xref target="TRACE"/>)
</t> </t>
<t> <t>
List-based grammar for <xref target="field.expect" format="none">Ex pect</xref> has been restored for compatibility with List-based grammar for <xref target="field.expect" format="none">Ex pect</xref> has been restored for compatibility with
RFC 2616 RFC 2616.
(<xref target="field.expect"/>). (<xref target="field.expect"/>)
</t> </t>
<t> <t>
<xref target="field.accept" format="none">Accept</xref> and <xref t arget="field.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response <xref target="field.accept" format="none">Accept</xref> and <xref t arget="field.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response
messages; the latter was introduced by <xref target="RFC7694"/> messages; the latter was introduced by <xref target="RFC7694"/>.
(<xref target="request.content.negotiation"/>). (<xref target="request.content.negotiation"/>)
</t> </t>
<t> <t>
"Accept Parameters" (accept-params and accept-ext ABNF production) have "Accept Parameters" (accept-params and accept-ext ABNF production) have
been removed from the definition of the Accept field been removed from the definition of the Accept field.
(<xref target="field.accept"/>). (<xref target="field.accept"/>)
</t> </t>
<t> <t>
The Accept-Charset field now is deprecated The Accept-Charset field now is deprecated.
(<xref target="field.accept-charset"/>). (<xref target="field.accept-charset"/>)
</t> </t>
<t> <t>
The semantics of "*" in the <xref target="field.vary" format="none" >Vary</xref> header field when other The semantics of "*" in the <xref target="field.vary" format="none" >Vary</xref> header field when other
values are present was clarified values are present was clarified.
(<xref target="field.vary"/>). (<xref target="field.vary"/>)
</t> </t>
<t> <t>
Range units are compared in a case-insensitive fashion Range units are compared in a case-insensitive fashion.
(<xref target="range.units"/>). (<xref target="range.units"/>)
</t> </t>
<t> <t>
The use of the Accept-Ranges field is not restricted to origin serv The use of the Accept-Ranges field is not restricted to origin serv
ers ers.
(<xref target="field.accept-ranges"/>). (<xref target="field.accept-ranges"/>)
</t> </t>
<t> <t>
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 has been added so that it's defined closer to status codes 301, 302
, and 307 , 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="HTTP2" section="9.1.2"/>) has been added because of i ts general <xref target="HTTP2" section="9.1.2"/>) has been added because of i ts 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="WEBDAV" section="11.2"/>) has been added because of i ts general <xref target="WEBDAV" section="11.2"/>) has been added because of i ts general
applicability applicability.
(<xref target="status.422"/>). (<xref target="status.422"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7232" title="Changes from R FC 7232"> <section anchor="changes.from.rfc.7232" title="Changes from R FC 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 gu ard determination of whether Last-Modified was a strong validator to gu ard
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 duri ng the generated from different clocks or at somewhat different times duri ng the
preparation of the response. This specification has relaxed that to allow preparation of the response. This specification has relaxed that to allow
reasonable discretion reasonable discretion.
(<xref target="lastmod.comparison"/>). (<xref target="lastmod.comparison"/>)
</t> </t>
<!-- [rfced] Section B.4. Does the following reordering improve <!-- [rfced] Section B.4. Does the following reordering improve
readability? readability?
Current: Current:
Removed edge-case requirement on If-Match and If-Unmodified-Since Removed edge-case requirement on If-Match and If-Unmodified-Since
that a validator not be sent in a 2xx response when validation fail s that a validator not be sent in a 2xx response when validation fail s
and the server decides that the same change request has already bee n and the server decides that the same change request has already bee n
applied. (Sections 13.1.1 and 13.1.4) applied. (Sections 13.1.1 and 13.1.4)
Perhaps: Perhaps:
The following edge-case requirement on If-Match and If-Unmodified-S ince The following edge-case requirement on If-Match and If-Unmodified-S ince
has been removed: the server does not send a validator in a 2xx res ponse has been removed: the server does not send a validator in a 2xx res ponse
when validation fails and the server decides that the same change when validation fails and the server decides that the same change
request has already been applied. (Sections 13.1.1 and S13.1.4) request has already been applied. (Sections 13.1.1 and S13.1.4)
--> -->
<t> <t>
Removed edge-case requirement on If-Match and If-Unmodified-Since t hat a Removed edge-case requirement on If-Match and If-Unmodified-Since t hat a
validator not be sent in a 2xx response when validation fails and t he server validator not be sent in a 2xx response when validation fails and t he server
decides that the same change request has already been applied decides that the same change request has already been applied.
(Sections <xref target="field.if-match" format="counter"/> and (Sections <xref target="field.if-match" format="counter"/> and
<xref target="field.if-unmodified-since" format="counter"/>). <xref target="field.if-unmodified-since" format="counter"/>)
</t> </t>
<t> <t>
The fact that If-Unmodified-Since does not apply to a resource with out a The fact that If-Unmodified-Since does not apply to a resource with out a
concept of modification time has been clarified concept of modification time has been clarified.
(<xref target="field.if-unmodified-since"/>). (<xref target="field.if-unmodified-since"/>)
</t> </t>
<t> <t>
Preconditions can now be evaluated before the request content is pr ocessed Preconditions can now be evaluated before the request content is pr ocessed
rather than waiting until the response would otherwise be successfu rather than waiting until the response would otherwise be successfu
l l.
(<xref target="evaluation"/>). (<xref target="evaluation"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7233" title="Changes from R FC 7233"> <section anchor="changes.from.rfc.7233" title="Changes from R FC 7233">
<t> <t>
Refactored the range-unit and ranges-specifier grammars to simplify Refactored the range-unit and ranges-specifier grammars to simplify
and reduce artificial distinctions between bytes and other and reduce artificial distinctions between bytes and other
(extension) range units, removing the overlapping grammar of (extension) range units, removing the overlapping grammar of
other-range-unit by defining range units generically as a token and other-range-unit by defining range units generically as a token and
placing extensions within the scope of a range-spec (other-range). placing extensions within the scope of a range-spec (other-range).
This disambiguates the role of list syntax (commas) in all range se ts, This disambiguates the role of list syntax (commas) in all range se ts,
including extension range units, for indicating a range-set of more than including extension range units, for indicating a range-set of more than
one range. Moving the extension grammar into range specifiers also allows one range. Moving the extension grammar into range specifiers also allows
protocol specific to byte ranges to be specified separately. protocol specific to byte ranges to be specified separately.
</t> </t>
<t> <t>
It is now possible to define Range handling on extension methods It is now possible to define Range handling on extension methods.
(<xref target="field.range"/>). (<xref target="field.range"/>)
</t> </t>
<t> <t>
Described use of the <xref target="field.content-range" format="non e">Content-Range</xref> header field Described use of the <xref target="field.content-range" format="non e">Content-Range</xref> header field
(<xref target="field.content-range"/>) as a request modifier to per form a (<xref target="field.content-range"/>) as a request modifier to per form a
partial PUT partial PUT.
(<xref target="partial.PUT"/>). (<xref target="partial.PUT"/>)
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7235" title="Changes from R FC 7235"> <section anchor="changes.from.rfc.7235" title="Changes from R FC 7235">
<t> <t>
None. None.
</t> </t>
</section> </section>
<section anchor="changes.from.rfc.7538" title="Changes from R FC 7538"> <section anchor="changes.from.rfc.7538" title="Changes from R FC 7538">
<t> <t>
None. None.
 End of changes. 133 change blocks. 
193 lines changed or deleted 191 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/