Movatterモバイル変換

[0]ホーム
URL:

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

This html diff was produced by rfcdiff 1.48. The latest version is available fromhttp://tools.ietf.org/tools/rfcdiff/
[8]ページ先頭
©2009-2026 Movatter.jp