rfc9110.xml   rfc9110-to-be-v7.xml 
skipping to change at line 235 skipping to change at line 235
status codes that describe the response (<xref target="status.codes"/>), and status codes that describe the response (<xref target="status.codes"/>), and
other control data and resource metadata that might be given in response other control data and resource metadata that might be given in response
fields. fields.
</t> </t>
<t> <t>
<iref item="content negotiation"/> <iref item="content negotiation"/>
Semantics also include representation metadata that describe how Semantics also include representation metadata that describe how
content is intended to be interpreted by a recipient, request header content is intended to be interpreted by a recipient, request header
fields that might influence content selection, and the various selection fields that might influence content selection, and the various selection
algorithms that are collectively referred to as algorithms that are collectively referred to as
<em>content negotiation</em> (<xref target="content.negotiation"/>). "content negotiation" (<xref target="content.negotiation"/>).
</t> </t>
</section> </section>
<section anchor="specifications.obsoleted.by.this.document" <section anchor="specifications.obsoleted.by.this.document"
title="Specifications Obsoleted by This Document"> title="Specifications Obsoleted by This Document">
<table align="left"> <table align="left">
<name>Specifications Obsoleted by This Document</name> <name>Specifications Obsoleted by This Document</name>
<thead> <thead>
<tr> <tr>
skipping to change at line 372 skipping to change at line 372
in strings defined in <xref target="RFC7405"/>. in strings defined in <xref target="RFC7405"/>.
</t> </t>
<t> <t>
It also uses a list extension, defined in <xref target="abnf.extension"/>, It also uses a list extension, defined in <xref target="abnf.extension"/>,
that allows for compact definition of comma-separated lists using a "#" that allows for compact definition of comma-separated lists using a "#"
operator (similar to how the "*" operator indicates repetition). <xref target ="collected.abnf"/> shows the collected grammar with all list operator (similar to how the "*" operator indicates repetition). <xref target ="collected.abnf"/> shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
</t> </t>
<t> <t>
As a convention, ABNF rule names prefixed with "obs-" denote As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons. obsolete grammar rules that appear for historical reasons.
</t> </t>
<t anchor="core.rules"> <t anchor="core.rules">
The following core rules are included by The following core rules are included by
reference, as defined in <xref target="RFC5234" section="B.1"/>: reference, as defined in <xref target="RFC5234" section="B.1"/>:
ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
DIGIT (decimal 0-9), DQUOTE (double quote), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
OCTET (any 8-bit sequence of data), SP (space), and OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
skipping to change at line 519 skipping to change at line 519
</t> </t>
<t> <t>
Some requests can be automatically retried by a client in the event of Some requests can be automatically retried by a client in the event of
an underlying connection failure, as described in an underlying connection failure, as described in
<xref target="idempotent.methods"/>. <xref target="idempotent.methods"/>.
</t> </t>
</section> </section>
<section anchor="protocol.version" title="Protocol Version"> <section anchor="protocol.version" title="Protocol Version">
<t> <t>
HTTP's version number consists of two decimal digits separated by a "." HTTP's version number consists of two decimal digits separated by a "."
(period or decimal point). The first digit ("major version") indicates the (period or decimal point). The first digit (major version) indicates the
messaging syntax, whereas the second digit ("minor version") messaging syntax, whereas the second digit (minor version)
indicates the highest minor version within that major version to which the indicates the highest minor version within that major version to which the
sender is conformant (able to understand for future communication). sender is conformant (able to understand for future communication).
</t> </t>
<t> <t>
While HTTP's core semantics don't change between protocol versions, the While HTTP's core semantics don't change between protocol versions, the
expression of them "on the wire" can change, and so the expression of them "on the wire" can change, and so the
HTTP version number changes when incompatible changes are made to the wire HTTP version number changes when incompatible changes are made to the wire
format. Additionally, HTTP allows incremental, backwards-compatible format. Additionally, HTTP allows incremental, backwards-compatible
changes to be made to the protocol without changing its version through changes to be made to the protocol without changing its version through
the use of defined extension points (<xref target="extending"/>). the use of defined extension points (<xref target="extending"/>).
skipping to change at line 569 skipping to change at line 569
<section anchor="terminology" title="Terminology and Core Concepts"> <section anchor="terminology" title="Terminology and Core Concepts">
<t> <t>
HTTP was created for the World Wide Web (WWW) architecture HTTP was created for the World Wide Web (WWW) architecture
and has evolved over time to support the scalability needs of a worldwide and has evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the terminology hypertext system. Much of that architecture is reflected in the terminology
used to define HTTP. used to define HTTP.
</t> </t>
<section anchor="resources" title="Resources"> <section anchor="resources" title="Resources">
<iref primary="true" item="resource"/> <iref primary="true" item="resource"/>
<t> <t>
The target of an HTTP request is called a <em>resource</em>. The target of an HTTP request is called a "resource".
HTTP does not limit the nature of a resource; it merely HTTP does not limit the nature of a resource; it merely
defines an interface that might be used to interact with resources. defines an interface that might be used to interact with resources.
Most resources are identified by a Uniform Resource Identifier (URI), as Most resources are identified by a Uniform Resource Identifier (URI), as
described in <xref target="uri"/>. described in <xref target="uri"/>.
</t> </t>
<t> <t>
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (<xref target="methods"/>) and a few semantics in the request method (<xref target="methods"/>) and a few
request-modifying header fields. request-modifying header fields.
skipping to change at line 595 skipping to change at line 595
</t> </t>
<t> <t>
HTTP relies upon the Uniform Resource Identifier (URI) HTTP relies upon the Uniform Resource Identifier (URI)
standard <xref target="URI"/> to indicate the target resource standard <xref target="URI"/> to indicate the target resource
(<xref target="target.resource"/>) and relationships between resources. (<xref target="target.resource"/>) and relationships between resources.
</t> </t>
</section> </section>
<section anchor="representations" title="Representations"> <section anchor="representations" title="Representations">
<iref primary="true" item="representation"/> <iref primary="true" item="representation"/>
<t> <t>
A <em>representation</em> is information A "representation" 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
potentially unbounded stream of representation data potentially unbounded stream of representation data
(<xref target="representation.data.and.metadata"/>). (<xref target="representation.data.and.metadata"/>).
</t> </t>
<t> <t>
HTTP allows "information hiding" behind its uniform interface by defining HTTP allows "information hiding" behind its uniform interface by defining
communication with respect to a transferable representation of the resource communication with respect to a transferable representation of the resource
state, rather than transferring the resource itself. This allows the state, rather than transferring the resource itself. This allows the
skipping to change at line 628 skipping to change at line 628
that help guide the recipient's future interactions. that help guide the recipient's future interactions.
</t> </t>
<t anchor="selected.representation"> <t anchor="selected.representation">
<iref primary="true" item="selected representation"/> <iref primary="true" item="selected representation"/>
A <xref target="target.resource" format="none">target resource</xref> might b e provided with, or be capable of A <xref target="target.resource" format="none">target resource</xref> might b e provided with, or be capable of
generating, multiple representations that are each intended to reflect the generating, multiple representations that are each intended to reflect the
resource's current state. An algorithm, usually based on resource's current state. An algorithm, usually based on
<xref target="content.negotiation" format="none">content negotiation</xref> ( <xref target="content.negotiation"/>), <xref target="content.negotiation" format="none">content negotiation</xref> ( <xref target="content.negotiation"/>),
would be used to select one of those representations as being most would be used to select one of those representations as being most
applicable to a given request. applicable to a given request.
This <em>selected representation</em> provides the data and metadata This "selected representation" provides the data and metadata
for evaluating conditional requests (<xref target="conditional.requests"/>) for evaluating conditional requests (<xref target="conditional.requests"/>)
and constructing the content for <xref target="status.200" format="none">200 (OK)</xref>, and constructing the content for <xref target="status.200" format="none">200 (OK)</xref>,
<xref target="status.206" format="none">206 (Partial Content)</xref>, and <xref target="status.206" format="none">206 (Partial Content)</xref>, and
<xref target="status.304" format="none">304 (Not Modified)</xref> responses t o GET (<xref target="GET"/>). <xref target="status.304" format="none">304 (Not Modified)</xref> responses t o GET (<xref target="GET"/>).
</t> </t>
</section> </section>
<section anchor="connections" title="Connections, Clients, and Servers" > <section anchor="connections" title="Connections, Clients, and Servers" >
<iref primary="true" item="client"/> <iref primary="true" item="client"/>
<iref primary="true" item="server"/> <iref primary="true" item="server"/>
<iref primary="true" item="connection"/> <iref primary="true" item="connection"/>
<t> <t>
HTTP is a client/server protocol that operates over a reliable HTTP is a client/server protocol that operates over a reliable
transport- or session-layer <em>connection</em>. transport- or session-layer "connection".
</t> </t>
<t> <t>
An HTTP <em>client</em> is a program that establishes a connection An HTTP "client" is a program that establishes a connection
to a server for the purpose of sending one or more HTTP requests. to a server for the purpose of sending one or more HTTP requests.
An HTTP <em>server</em> is a program that accepts connections An HTTP "server" is a program that accepts connections
in order to service HTTP requests by sending HTTP responses. in order to service HTTP requests by sending HTTP responses.
</t> </t>
<t> <t>
The terms "client" and "server" refer only to the roles that The terms client and server refer only to the roles that
these programs perform for a particular connection. The same program these programs perform for a particular connection. The same program
might act as a client on some connections and a server on others. might act as a client on some connections and a server on others.
</t> </t>
<t> <t>
HTTP is defined as a stateless protocol, meaning that each request message's semantics HTTP is defined as a stateless protocol, meaning that each request message's semantics
can be understood in isolation, and that the relationship between connections can be understood in isolation, and that the relationship between connections
and messages on them has no impact on the interpretation of those messages. and messages on them has no impact on the interpretation of those messages.
For example, a CONNECT request (<xref target="CONNECT"/>) or a request with For example, a CONNECT request (<xref target="CONNECT"/>) or a request with
the Upgrade header field (<xref target="field.upgrade"/>) can occur at any ti me, the Upgrade header field (<xref target="field.upgrade"/>) can occur at any ti me,
not just in the first message on a connection. Many implementations depend on not just in the first message on a connection. Many implementations depend on
skipping to change at line 682 skipping to change at line 682
</section> </section>
<section anchor="messages" title="Messages"> <section anchor="messages" title="Messages">
<iref primary="true" item="messages"/> <iref primary="true" item="messages"/>
<iref item="message"/> <iref item="message"/>
<iref primary="true" item="sender"/> <iref primary="true" item="sender"/>
<iref primary="true" item="recipient"/> <iref primary="true" item="recipient"/>
<iref primary="true" item="request"/> <iref primary="true" item="request"/>
<iref primary="true" item="response"/> <iref primary="true" item="response"/>
<t> <t>
HTTP is a stateless request/response protocol for exchanging HTTP is a stateless request/response protocol for exchanging
<em>messages</em> across a <xref target="connections" format="none">connectio "messages" across a <xref target="connections" format="none">connection</xref
n</xref>. >.
The terms <em>sender</em> and <em>recipient</em> refer to The terms "sender" and "recipient" refer to
any implementation that sends or receives a given message, respectively. any implementation that sends or receives a given message, respectively.
</t> </t>
<t> <t>
A client sends requests to a server in the form of a <em>request</em> A client sends requests to a server in the form of a "request"
message with a method (<xref target="methods"/>) and request target message with a method (<xref target="methods"/>) and request target
(<xref target="target.resource"/>). The request might also contain (<xref target="target.resource"/>). The request might also contain
header fields (<xref target="header.fields"/>) for request modifiers, header fields (<xref target="header.fields"/>) for request modifiers,
client information, and representation metadata, client information, and representation metadata,
content (<xref target="content"/>) intended for processing content (<xref target="content"/>) intended for processing
in accordance with the method, and in accordance with the method, and
trailer fields (<xref target="trailer.fields"/>) to communicate information trailer fields (<xref target="trailer.fields"/>) to communicate information
collected while sending the content. collected while sending the content.
</t> </t>
<t> <t>
A server responds to a client's request by sending one or more A server responds to a client's request by sending one or more
<em>response</em> messages, each including a status "response" messages, each including a status
code (<xref target="status.codes"/>). The response might also contain code (<xref target="status.codes"/>). The response might also contain
header fields for server information, resource metadata, and representation header fields for server information, resource metadata, and representation
metadata, content to be interpreted in accordance with the status metadata, content to be interpreted in accordance with the status
code, and trailer fields to communicate information code, and trailer fields to communicate information
collected while sending the content. collected while sending the content.
</t> </t>
</section> </section>
<section anchor="user.agent" title="User Agents"> <section anchor="user.agent" title="User Agents">
<iref primary="true" item="user agent"/> <iref primary="true" item="user agent"/>
<iref primary="true" item="browser"/> <iref primary="true" item="browser"/>
<iref primary="true" item="spider"/> <iref primary="true" item="spider"/>
<t> <t>
The term <em>user agent</em> refers to any of the various The term "user agent" refers to any of the various
client programs that initiate a request. client programs that initiate a request.
</t> </t>
<t> <t>
The most familiar form of user agent is the general-purpose Web browser, but The most familiar form of user agent is the general-purpose Web browser, but
that's only a small percentage of implementations. Other common user agents that's only a small percentage of implementations. Other common user agents
include spiders (web-traversing robots), command-line tools, billboard include spiders (web-traversing robots), command-line tools, billboard
screens, household appliances, scales, light bulbs, firmware update scripts, screens, household appliances, scales, light bulbs, firmware update scripts,
mobile apps, and communication devices in a multitude of shapes and sizes. mobile apps, and communication devices in a multitude of shapes and sizes.
</t> </t>
<t> <t>
skipping to change at line 747 skipping to change at line 747
Likewise, requirements that an automated action be confirmed by the user Likewise, requirements that an automated action be confirmed by the user
before proceeding might be met via advance configuration choices, before proceeding might be met via advance configuration choices,
run-time options, or simple avoidance of the unsafe action; confirmation run-time options, or simple avoidance of the unsafe action; confirmation
does not imply any specific user interface or interruption of normal does not imply any specific user interface or interruption of normal
processing if the user has already made that choice. processing if the user has already made that choice.
</t> </t>
</section> </section>
<section anchor="origin.server" title="Origin Server"> <section anchor="origin.server" title="Origin Server">
<iref primary="true" item="origin server"/> <iref primary="true" item="origin server"/>
<t> <t>
The term <em>origin server</em> refers to a program that can The term "origin server" refers to a program that can
originate authoritative responses for a given target resource. originate authoritative responses for a given target resource.
</t> </t>
<t> <t>
The most familiar form of origin server are large public websites. The most familiar form of origin server are large public websites.
However, like user agents being equated with browsers, it is easy to be However, like user agents being equated with browsers, it is easy to be
misled into thinking that all origin servers are alike. misled into thinking that all origin servers are alike.
Common origin servers also include home automation units, configurable Common origin servers also include home automation units, configurable
networking components, office machines, autonomous robots, news feeds, networking components, office machines, autonomous robots, news feeds,
traffic cameras, real-time ad selectors, and video-on-demand platforms. traffic cameras, real-time ad selectors, and video-on-demand platforms.
</t> </t>
skipping to change at line 784 skipping to change at line 784
UA ======================================= O UA ======================================= O
< response < response
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="intermediaries" title="Intermediaries"> <section anchor="intermediaries" title="Intermediaries">
<iref primary="true" item="intermediary"/> <iref primary="true" item="intermediary"/>
<t> <t>
HTTP enables the use of intermediaries to satisfy requests through HTTP enables the use of intermediaries to satisfy requests through
a chain of connections. There are three common forms of HTTP a chain of connections. There are three common forms of HTTP
<em>intermediary</em>: proxy, gateway, and tunnel. In some cases, "intermediary": proxy, gateway, and tunnel. In some cases,
a single intermediary might act as an origin server, proxy, gateway, a single intermediary might act as an origin server, proxy, gateway,
or tunnel, switching behavior based on the nature of each request. or tunnel, switching behavior based on the nature of each request.
</t> </t>
<figure> <figure>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
]]></artwork> ]]></artwork>
</figure> </figure>
skipping to change at line 815 skipping to change at line 815
forwarding requests to servers other than C, at the same time that it forwarding requests to servers other than C, at the same time that it
is handling A's request. Likewise, later requests might be sent through a is handling A's request. Likewise, later requests might be sent through a
different path of connections, often based on dynamic configuration for different path of connections, often based on dynamic configuration for
load balancing. load balancing.
</t> </t>
<t> <t>
<iref primary="true" item="upstream"/> <iref primary="true" item="upstream"/>
<iref primary="true" item="downstream"/> <iref primary="true" item="downstream"/>
<iref primary="true" item="inbound"/> <iref primary="true" item="inbound"/>
<iref primary="true" item="outbound"/> <iref primary="true" item="outbound"/>
The terms <em>upstream</em> and <em>downstream</em> are The terms "upstream" and "downstream" are
used to describe directional requirements in relation to the message flow: used to describe directional requirements in relation to the message flow:
all messages flow from upstream to downstream. all messages flow from upstream to downstream.
The terms "inbound" and "outbound" are used to describe directional The terms "inbound" and "outbound" are used to describe directional
requirements in relation to the request route: requirements in relation to the request route:
<em>inbound</em> means toward the origin server and inbound means "toward the origin server", whereas
<em>outbound</em> means toward the user agent. outbound means "toward the user agent".
</t> </t>
<t> <t>
<iref primary="true" item="proxy"/> <iref primary="true" item="proxy"/>
A <em>proxy</em> is a message-forwarding agent that is chosen by the A "proxy" is a message-forwarding agent that is chosen by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some translations requests via translation through the HTTP interface. Some translations
are minimal, such as for proxy requests for "http" URIs, whereas are minimal, such as for proxy requests for "http" URIs, whereas
other requests might require translation to and from entirely different other requests might require translation to and from entirely different
application-level protocols. Proxies are often used to group an application-level protocols. Proxies are often used to group an
organization's HTTP requests through a common intermediary for the organization's HTTP requests through a common intermediary for the
sake of security services, annotation services, or shared caching. Some sake of security services, annotation services, or shared caching. Some
proxies are designed to apply transformations to selected messages or proxies are designed to apply transformations to selected messages or
content while they are being forwarded, as described in content while they are being forwarded, as described in
<xref target="message.transformations"/>. <xref target="message.transformations"/>.
</t> </t>
<t> <t>
<iref primary="true" item="gateway"/> <iref primary="true" item="gateway"/>
<iref primary="true" item="reverse proxy"/> <iref primary="true" item="reverse proxy"/>
<iref primary="true" item="accelerator"/> <iref primary="true" item="accelerator"/>
A <em>gateway</em> (a.k.a. <em>reverse proxy</em>) is an A "gateway" (a.k.a. "reverse proxy") is an
intermediary that acts as an origin server for the outbound connection but intermediary that acts as an origin server for the outbound connection but
translates received requests and forwards them inbound to another server or translates received requests and forwards them inbound to another server or
servers. Gateways are often used to encapsulate legacy or untrusted servers. Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
<em>accelerator</em> caching, and to enable partitioning or load "accelerator" caching, and to enable partitioning or load
balancing of HTTP services across multiple machines. balancing of HTTP services across multiple machines.
</t> </t>
<t> <t>
All HTTP requirements applicable to an origin server All HTTP requirements applicable to an origin server
also apply to the outbound communication of a gateway. also apply to the outbound communication of a gateway.
A gateway communicates with inbound servers using any protocol that A gateway communicates with inbound servers using any protocol that
it desires, including private extensions to HTTP that are outside it desires, including private extensions to HTTP that are outside
the scope of this specification. However, an HTTP-to-HTTP gateway the scope of this specification. However, an HTTP-to-HTTP gateway
that wishes to interoperate with third-party HTTP servers needs to conform that wishes to interoperate with third-party HTTP servers needs to conform
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 "tunnel" acts as a blind relay between two connections
without changing the messages. Once active, a tunnel is not without changing the messages. Once active, a tunnel is not
considered a party to the HTTP communication, though the tunnel might considered a party to the HTTP communication, though the tunnel might
have been initiated by an HTTP request. A tunnel ceases to exist when have been initiated by an HTTP request. A tunnel ceases to exist when
both ends of the relayed connection are closed. Tunnels are used to both ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, <xref target="TLS13"/>) is used to Transport Layer Security (TLS, <xref target="TLS13"/>) is used to
establish confidential communication through a shared firewall proxy. establish confidential communication through a shared firewall proxy.
</t> </t>
<t> <t>
The above categories for intermediary only consider those acting as The above categories for intermediary only consider those acting as
skipping to change at line 883 skipping to change at line 883
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.
</t> </t>
<t> <t>
<iref primary="true" item="interception proxy"/> <iref primary="true" item="interception proxy"/>
<iref primary="true" item="transparent proxy"/> <iref primary="true" item="transparent proxy"/>
For example, an For example, an "interception proxy" <xref target="RFC3040"/> (also commonly
<em>interception proxy</em> known as a "transparent proxy" <xref target="RFC1919"/>)
<xref target="RFC3040"/> (also commonly
known as a <em>transparent proxy</em>
<xref target="RFC1919"/>)
differs from an HTTP proxy because it is not chosen by the client. differs from an HTTP proxy because it is not chosen by the client.
Instead, an interception proxy filters or redirects outgoing TCP port 80 Instead, an interception proxy filters or redirects outgoing TCP port 80
packets (and occasionally other common port traffic). packets (and occasionally other common port traffic).
Interception proxies are commonly found on public network access points, Interception proxies are commonly found on public network access points,
as a means of enforcing account subscription prior to allowing use of as a means of enforcing account subscription prior to allowing use of
non-local Internet services, and within corporate firewalls to enforce non-local Internet services, and within corporate firewalls to enforce
network usage policies. network usage policies.
</t> </t>
</section> </section>
<section anchor="caches" title="Caches"> <section anchor="caches" title="Caches">
<iref primary="true" item="cache"/> <iref primary="true" item="cache"/>
<t> <t>
A <em>cache</em> is a local store of previous response messages and the A "cache" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion. subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent time and network bandwidth consumption on future, equivalent
requests. Any client or server <bcp14>MAY</bcp14> employ a cache, though a ca che requests. Any client or server <bcp14>MAY</bcp14> employ a cache, though a ca che
cannot be used while acting as a tunnel. cannot be used while acting as a tunnel.
</t> </t>
<t> <t>
The effect of a cache is that the request/response chain is shortened The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting applicable to that request. The following illustrates the resulting
skipping to change at line 923 skipping to change at line 920
</t> </t>
<figure> <figure>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
> > > >
UA =========== A =========== B - - - - - - C - - - - - - O UA =========== A =========== B - - - - - - C - - - - - - O
< < < <
]]></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 "cacheable" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. the response message for use in answering subsequent requests.
Even when a response is cacheable, there might be additional Even when a response is cacheable, there might be additional
constraints placed by the client or by the origin server on when constraints placed by the client or by the origin server on when
that cached response can be used for a particular request. HTTP that cached response can be used for a particular request. HTTP
requirements for cache behavior and cacheable responses are requirements for cache behavior and cacheable responses are
defined in <xref target="CACHING"/>. defined in <xref target="CACHING"/>.
</t> </t>
<t> <t>
There is a wide variety of architectures and configurations There is a wide variety of architectures and configurations
of caches deployed across the World Wide Web and of caches deployed across the World Wide Web and
skipping to change at line 1152 skipping to change at line 1149
</section> </section>
<section anchor="https.uri" title="https URI Scheme"> <section anchor="https.uri" title="https URI Scheme">
<iref item="https URI scheme" primary="true"/> <iref item="https URI scheme" primary="true"/>
<iref item="URI scheme" subitem="https" primary="true"/> <iref item="URI scheme" subitem="https" primary="true"/>
<iref item="secured" primary="true"/> <iref item="secured" primary="true"/>
<t> <t>
The "https" URI scheme is hereby defined for minting identifiers within the The "https" URI scheme is hereby defined for minting identifiers within the
hierarchical namespace governed by a potential origin server listening for hierarchical namespace governed by a potential origin server listening for
TCP connections on a given port and capable of establishing a TLS TCP connections on a given port and capable of establishing a TLS
(<xref target="TLS13"/>) connection that has been secured for HTTP (<xref target="TLS13"/>) connection that has been secured for HTTP
communication. In this context, <em>secured</em> specifically communication. In this context, "secured" 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="abnf9110"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ] <sourcecode type="abnf9110"><![CDATA[ https-URI = "https" "://" authority path-abempty [ "?" query ]
]]></sourcecode> ]]></sourcecode>
<t> <t>
skipping to change at line 1328 skipping to change at line 1325
peer has the authority to represent an origin. peer has the authority to represent an origin.
</t> </t>
<t> <t>
See <xref target="establishing.authority"/> for security considerations See <xref target="establishing.authority"/> for security considerations
related to establishing authority. related to establishing authority.
</t> </t>
<section anchor="origin" title="URI Origin"> <section anchor="origin" title="URI Origin">
<iref primary="true" item="origin"/> <iref primary="true" item="origin"/>
<iref primary="true" item="URI" subitem="origin"/> <iref primary="true" item="URI" subitem="origin"/>
<t> <t>
The <em>origin</em> for a given URI is the triple of scheme, host, The "origin" for a given URI is the triple of scheme, host,
and port after normalizing the scheme and host to lowercase and and port after normalizing the scheme and host to lowercase and
normalizing the port to remove any leading zeros. If port is elided from normalizing the port to remove any leading zeros. If port is elided from
the URI, the default port for that scheme is used. For example, the URI the URI, the default port for that scheme is used. For example, the URI
</t> </t>
<artwork type="example"><![CDATA[ <artwork type="example"><![CDATA[
https://Example.Com/happy.js https://Example.Com/happy.js
]]></artwork> ]]></artwork>
<t> <t>
would have the origin would have the origin
</t> </t>
skipping to change at line 1355 skipping to change at line 1352
</t> </t>
<artwork type="example"><![CDATA[ <artwork type="example"><![CDATA[
https://example.com:443 https://example.com:443
]]></artwork> ]]></artwork>
<t> <t>
Each origin defines its own namespace and controls how identifiers Each origin defines its own namespace and controls how identifiers
within that namespace are mapped to resources. In turn, how the origin within that namespace are mapped to resources. In turn, how the origin
responds to valid requests, consistently over time, determines the responds to valid requests, consistently over time, determines the
semantics that users will associate with a URI, and the usefulness of semantics that users will associate with a URI, and the usefulness of
those semantics is what ultimately transforms these mechanisms into a those semantics is what ultimately transforms these mechanisms into a
"resource" for users to reference and access in the future. resource for users to reference and access in the future.
</t> </t>
<t> <t>
Two origins are distinct if they differ in scheme, host, or port. Even Two origins are distinct if they differ in scheme, host, or port. Even
when it can be verified that the same entity controls two distinct origins, when it can be verified that the same entity controls two distinct origins,
the two namespaces under those origins are distinct unless explicitly the two namespaces under those origins are distinct unless explicitly
aliased by a server authoritative for that origin. aliased by a server authoritative for that origin.
</t> </t>
<t> <t>
Origin is also used within HTML and related Web protocols, beyond the Origin is also used within HTML and related Web protocols, beyond the
scope of this document, as described in <xref target="RFC6454"/>. scope of this document, as described in <xref target="RFC6454"/>.
skipping to change at line 1559 skipping to change at line 1556
<t> <t>
A reference identity of type IP-ID matches if the address is identical to A reference identity of type IP-ID matches if the address is identical to
an iPAddress value of the subjectAltName extension of the certificate. an iPAddress value of the subjectAltName extension of the certificate.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="fields" title="Fields"> <section anchor="fields" title="Fields">
<iref primary="true" item="field"/> <iref primary="true" item="field"/>
<t> <t>
HTTP uses <em>fields</em> to provide data in the form of extensible HTTP uses "fields" to provide data in the form of extensible
key/value pairs with a registered key namespace. Fields are sent and key/value pairs with a registered key namespace. Fields are sent and
received within the header and trailer sections of messages received within the header and trailer sections of messages
(<xref target="message.abstraction"/>). (<xref target="message.abstraction"/>).
</t> </t>
<section anchor="fields.names" title="Field Names"> <section anchor="fields.names" title="Field Names">
<t> <t>
A field name labels the corresponding field value as having the A field name labels the corresponding field value as having the
semantics defined by that name. For example, the <xref target="field.date" f ormat="none">Date</xref> semantics defined by that name. For example, the <xref target="field.date" f ormat="none">Date</xref>
header field is defined in <xref target="field.date"/> as containing the header field is defined in <xref target="field.date"/> as containing the
origination timestamp for the message in which it appears. origination timestamp for the message in which it appears.
skipping to change at line 1607 skipping to change at line 1604
Other recipients <bcp14>SHOULD</bcp14> ignore unrecognized header and trailer fields. Other recipients <bcp14>SHOULD</bcp14> ignore unrecognized header and trailer fields.
Adhering to these requirements allows HTTP's functionality to be extended Adhering to these requirements allows HTTP's functionality to be extended
without updating or removing deployed intermediaries. without updating or removing deployed intermediaries.
</t> </t>
</section> </section>
<section anchor="field.lines" title="Field Lines and Combined Field Val ue"> <section anchor="field.lines" title="Field Lines and Combined Field Val ue">
<t> <t>
<iref item="field line"/> <iref item="field line"/>
<iref item="field name"/> <iref item="field name"/>
<iref item="field line value"/> <iref item="field line value"/>
Field sections are composed of any number of <em>field lines</em>, Field sections are composed of any number of "field lines",
each with a <em>field name</em> (see <xref target="fields.names"/>) each with a "field name" (see <xref target="fields.names"/>)
identifying the field, and a <em>field line value</em> that conveys identifying the field, and a "field line value" that conveys
data for that instance of the field. data for that instance of the field.
</t> </t>
<t> <t>
<iref item="field value"/> <iref item="field value"/>
When a field name is only present once in a section, the combined When a field name is only present once in a section, the combined
<em>field value</em> for that field consists of the corresponding "field value" for that field consists of the corresponding
field line value. field line value.
When a field name is repeated within a section, its combined field value When a field name is repeated within a section, its combined field value
consists of the list of corresponding field line values within that section, consists of the list of corresponding field line values within that section,
concatenated in order, with each field line value separated by a comma. concatenated in order, with each field line value separated by a comma.
</t> </t>
<t> <t>
For example, this section: For example, this section:
</t> </t>
<sourcecode type="http-message"><![CDATA[Example-Field: Foo, Bar <sourcecode type="http-message"><![CDATA[Example-Field: Foo, Bar
Example-Field: Baz Example-Field: Baz
skipping to change at line 1757 skipping to change at line 1754
either reject the message or replace each of those characters with SP either reject the message or replace each of those characters with SP
before further processing or forwarding of that message. Field values before further processing or forwarding of that message. Field values
containing other CTL characters are also invalid; however, containing other CTL characters are also invalid; however,
recipients <bcp14>MAY</bcp14> retain such characters for the sake of robustne ss when recipients <bcp14>MAY</bcp14> retain such characters for the sake of robustne ss when
they appear within a safe context (e.g., an application-specific quoted they appear within a safe context (e.g., an application-specific quoted
string that will not be processed by any downstream HTTP parser). string that will not be processed by any downstream HTTP parser).
</t> </t>
<t> <t>
<iref item="singleton field"/> <iref item="singleton field"/>
Fields that only anticipate a single member as the field value are Fields that only anticipate a single member as the field value are
referred to as <em>singleton fields</em>. referred to as "singleton fields".
</t> </t>
<t> <t>
<iref item="list-based field"/> <iref item="list-based field"/>
Fields that allow multiple members as the field value are referred to as Fields that allow multiple members as the field value are referred to as
<em>list-based fields</em>. The list operator extension of "list-based fields". The list operator extension of
<xref target="abnf.extension"/> is used as a common notation for defining <xref target="abnf.extension"/> is used as a common notation for defining
field values that can contain multiple members. field values that can contain multiple members.
</t> </t>
<t> <t>
Because commas (",") are used as the delimiter between members, they need Because commas (",") are used as the delimiter between members, they need
to be treated with care if they are allowed as data within a member. This to be treated with care if they are allowed as data within a member. This
is true for both list-based and singleton fields, since a singleton field is true for both list-based and singleton fields, since a singleton field
might be erroneously sent with multiple members and detecting such errors might be erroneously sent with multiple members and detecting such errors
improves interoperability. Fields that expect to contain a improves interoperability. Fields that expect to contain a
comma within a member, such as within an <xref target="http.date" format="non e">HTTP-date</xref> or comma within a member, such as within an <xref target="http.date" format="non e">HTTP-date</xref> or
skipping to change at line 2094 skipping to change at line 2091
that contains one or more timestamps defined as HTTP-date, that contains one or more timestamps defined as HTTP-date,
the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate f ormat. the sender <bcp14>MUST</bcp14> generate those timestamps in the IMF-fixdate f ormat.
</t> </t>
<t> <t>
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor
of the UTC name; values in the asctime format are assumed to be in UTC. of the UTC name; values in the asctime format are assumed to be in UTC.
</t> </t>
<t> <t>
A <em>clock</em> is an implementation capable of providing a A "clock" is an implementation capable of providing a
reasonable approximation of the current instant in UTC. reasonable approximation of the current instant in UTC.
A clock implementation ought to use NTP (<xref target="RFC5905"/>), A clock implementation ought to use NTP (<xref target="RFC5905"/>),
or some similar protocol, to synchronize with UTC. or some similar protocol, to synchronize with UTC.
</t> </t>
<t anchor="preferred.date.format"> <t anchor="preferred.date.format">
Preferred format: Preferred format:
</t> </t>
<iref primary="true" item="Grammar" subitem="IMF-fixdate"/> <iref primary="true" item="Grammar" subitem="IMF-fixdate"/>
<iref primary="true" item="Grammar" subitem="date1"/> <iref primary="true" item="Grammar" subitem="date1"/>
skipping to change at line 2187 skipping to change at line 2184
</t> </t>
<t> <t>
Recipients of timestamp values are encouraged to be robust in parsing Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. timestamps unless otherwise restricted by the field definition.
For example, messages are occasionally forwarded over HTTP from a non-HTTP For example, messages are occasionally forwarded over HTTP from a non-HTTP
source that might generate any of the date and time specifications defined source that might generate any of the date and time specifications defined
by the Internet Message Format. by the Internet Message Format.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> HTTP requirements for the date/times tamp format apply only <strong>Note:</strong> HTTP requirements for the timestamp formats apply only
to their usage within the protocol stream. Implementations are to their usage within the protocol stream. Implementations are
not required to use these formats for user presentation, request not required to use these formats for user presentation, request
logging, etc. logging, etc.
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
</section> </section>
<section anchor="message.abstraction" title="Message Abstraction"> <section anchor="message.abstraction" title="Message Abstraction">
<iref primary="true" item="message abstraction"/> <iref primary="true" item="message abstraction"/>
skipping to change at line 2235 skipping to change at line 2232
* a headers lookup table of key/value pairs for extending that * a headers lookup table of key/value pairs for extending that
control data and conveying additional information about the control data and conveying additional information about the
sender, message, content, or context, sender, message, content, or context,
* a potentially unbounded stream of content, and * a potentially unbounded stream of content, and
* a trailers lookup table of key/value pairs for communicating * a trailers lookup table of key/value pairs for communicating
information obtained while sending the content. information obtained while sending the content.
--> -->
<t> <t>
A <em>message</em> consists of control data to describe and route the A "message" consists of control data to describe and route the
message, a headers lookup table of key/value pairs for extending that message, a headers lookup table of key/value pairs for extending that
control data and conveying additional information about the sender, message, control data and conveying additional information about the sender, message,
content, or context, a potentially unbounded stream of content, and a content, or context, a potentially unbounded stream of content, and a
trailers lookup table of key/value pairs for communicating information trailers lookup table of key/value pairs for communicating information
obtained while sending the content. obtained while sending the content.
</t> </t>
<t> <t>
Framing and control data is sent first, followed by a header section Framing and control data is sent first, followed by a header section
containing fields for the headers table. When a message includes content, containing fields for the headers table. When a message includes content,
the content is sent after the header section, potentially followed by a the content is sent after the header section, potentially followed by a
skipping to change at line 2258 skipping to change at line 2255
<t> <t>
Messages are expected to be processed as a stream, wherein the purpose of Messages are expected to be processed as a stream, wherein the purpose of
that stream and its continued processing is revealed while being read. that stream and its continued processing is revealed while being read.
Hence, control data describes what the recipient needs to know immediately, Hence, control data describes what the recipient needs to know immediately,
header fields describe what needs to be known before receiving content, header fields describe what needs to be known before receiving content,
the content (when present) presumably contains what the recipient wants or the content (when present) presumably contains what the recipient wants or
needs to fulfill the message semantics, and trailer fields provide needs to fulfill the message semantics, and trailer fields provide
optional metadata that was unknown prior to sending the content. optional metadata that was unknown prior to sending the content.
</t> </t>
<t> <t>
Messages are intended to be <em>self-descriptive</em>: Messages are intended to be "self-descriptive":
everything a recipient needs to know about the message can be determined by everything a recipient needs to know about the message can be determined by
looking at the message itself, after decoding or reconstituting parts that looking at the message itself, after decoding or reconstituting parts that
have been compressed or elided in transit, without requiring an have been compressed or elided in transit, without requiring an
understanding of the sender's current application state (established via understanding of the sender's current application state (established via
prior messages). However, a client <bcp14>MUST</bcp14> retain knowledge of th e request when prior messages). However, a client <bcp14>MUST</bcp14> retain knowledge of th e request when
parsing, interpreting, or caching a corresponding response. For example, parsing, interpreting, or caching a corresponding response. For example,
responses to the <xref target="HEAD" format="none">HEAD</xref> method look ju st like the beginning of a responses to the <xref target="HEAD" format="none">HEAD</xref> method look ju st like the beginning of a
response to <xref target="GET" format="none">GET</xref> but cannot be parsed in the same manner. response to <xref target="GET" format="none">GET</xref> but cannot be parsed in the same manner.
</t> </t>
<t> <t>
skipping to change at line 2293 skipping to change at line 2290
</t> </t>
<t> <t>
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying
connection to end a response. For backwards compatibility, this implicit connection to end a response. For backwards compatibility, this implicit
framing is also allowed in HTTP/1.1. However, implicit framing can fail to framing is also allowed in HTTP/1.1. However, implicit framing can fail to
distinguish an incomplete response if the connection closes early. For distinguish an incomplete response if the connection closes early. For
that reason, almost all modern implementations use explicit framing in that reason, almost all modern implementations use explicit framing in
the form of length-delimited sequences of message data. the form of length-delimited sequences of message data.
</t> </t>
<t> <t>
A message is considered <em>complete</em> when all of the octets A message is considered "complete" when all of the octets
indicated by its framing are available. Note that, indicated by its framing are available. Note that,
when no explicit framing is used, a response message that is ended when no explicit framing is used, a response message that is ended
by the underlying connection's close is considered complete even though it by the underlying connection's close is considered complete even though it
might be indistinguishable from an incomplete response, unless a might be indistinguishable from an incomplete response, unless a
transport-level error indicates that it is not complete. transport-level error indicates that it is not complete.
</t> </t>
</section> </section>
<section anchor="message.control.data" title="Control Data"> <section anchor="message.control.data" title="Control Data">
<iref primary="true" item="control data"/> <iref primary="true" item="control data"/>
<t> <t>
skipping to change at line 2372 skipping to change at line 2369
</t> </t>
</section> </section>
<section anchor="header.fields" title="Header Fields"> <section anchor="header.fields" title="Header Fields">
<iref primary="true" item="header section"/> <iref primary="true" item="header section"/>
<iref item="field"/> <iref item="field"/>
<t> <t>
Fields (<xref target="fields"/>) that are sent or received before the content Fields (<xref target="fields"/>) that are sent or received before the content
are referred to as "header fields" (or just "headers", colloquially). are referred to as "header fields" (or just "headers", colloquially).
</t> </t>
<t> <t>
The <em>header section</em> of a message consists of a sequence of The "header section" of a message consists of a sequence of
header field lines. Each header field might modify or extend message header field lines. Each header field might modify or extend message
semantics, describe the sender, define the content, or provide additional semantics, describe the sender, define the content, or provide additional
context. context.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> We refer to named fields specifically a s a "header field" when they <strong>Note:</strong> We refer to named fields specifically a s a "header field" when they
are only allowed to be sent in the header section. are only allowed to be sent in the header section.
</t> </t>
</aside> </aside>
</section> </section>
<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 "content": a stream of octets sent after the header
section, as delineated by the message framing. section, as delineated by the message framing.
</t> </t>
<t> <t>
This abstract definition of content reflects the data after it has been This abstract definition of content reflects the data after it has been
extracted from the message framing. For example, an HTTP/1.1 message body extracted from the message framing. For example, an HTTP/1.1 message body
(<xref target="HTTP11" section="6"/>) might consist of a stream of data encod ed (<xref target="HTTP11" section="6"/>) might consist of a stream of data encod ed
with the chunked transfer coding -- a sequence of data chunks, one with the chunked transfer coding -- a sequence of data chunks, one
zero-length chunk, and a trailer section -- whereas zero-length chunk, and a trailer section -- whereas
the content of that same message the content of that same message
includes only the data stream after the transfer coding has been decoded; includes only the data stream after the transfer coding has been decoded;
skipping to change at line 2530 skipping to change at line 2527
identifier might be supplied within the content itself.</li> identifier might be supplied within the content itself.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="trailer.fields" title="Trailer Fields"> <section anchor="trailer.fields" title="Trailer Fields">
<iref primary="true" item="trailer section"/> <iref primary="true" item="trailer section"/>
<iref primary="true" item="Trailer Fields"/> <iref primary="true" item="Trailer Fields"/>
<iref primary="true" item="trailers"/> <iref primary="true" item="trailers"/>
<t> <t>
Fields (<xref target="fields"/>) that are located within a Fields (<xref target="fields"/>) that are located within a
<em>trailer section</em> are referred to as "trailer fields" "trailer section" are referred to as "trailer fields"
(or just "trailers", colloquially). (or just "trailers", colloquially).
Trailer fields can be useful for supplying message integrity checks, digital Trailer fields can be useful for supplying message integrity checks, digital
signatures, delivery metrics, or post-processing status information. signatures, delivery metrics, or post-processing status information.
</t> </t>
<t> <t>
Trailer fields ought to be processed and stored separately from the fields Trailer fields ought to be processed and stored separately from the fields
in the header section to avoid contradicting message semantics known at in the header section to avoid contradicting message semantics known at
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;
skipping to change at line 2727 skipping to change at line 2724
<iref primary="true" item="request target"/> <iref primary="true" item="request target"/>
<t> <t>
Although HTTP is used in a wide variety of applications, most clients rely Although HTTP is used in a wide variety of applications, most clients rely
on the same resource identification mechanism and configuration techniques on the same resource identification mechanism and configuration techniques
as general-purpose Web browsers. Even when communication options are as general-purpose Web browsers. Even when communication options are
hard-coded in a client's configuration, we can think of their combined hard-coded in a client's configuration, we can think of their combined
effect as a URI reference (<xref target="uri.references"/>). effect as a URI reference (<xref target="uri.references"/>).
</t> </t>
<t> <t>
A URI reference is resolved to its absolute form in order to obtain the A URI reference is resolved to its absolute form in order to obtain the
<em>target URI</em>. The target URI excludes the reference's "target URI". The target URI excludes the reference's
fragment component, if any, since fragment identifiers are reserved for fragment component, if any, since fragment identifiers are reserved for
client-side processing (<xref target="URI" sectionFormat="comma" section="3.5 "/>). client-side processing (<xref target="URI" sectionFormat="comma" section="3.5 "/>).
</t> </t>
<t> <t>
To perform an action on a <em>target resource</em>, the client sends To perform an action on a "target resource", 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 "request target", are sent within the message control data
and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>). and the <xref target="field.host" format="none">Host</xref> header field (<xr ef target="field.host"/>).
</t> </t>
<t> <t>
There are two unusual cases for which the request target components are in There are two unusual cases for which the request target components are in
a method-specific form: a method-specific form:
</t> </t>
<ul> <ul>
<li> <li>
For CONNECT (<xref target="CONNECT"/>), the request target is the host For CONNECT (<xref target="CONNECT"/>), the request target is the host
name and port number of the tunnel destination, separated by a colon. name and port number of the tunnel destination, separated by a colon.
skipping to change at line 2769 skipping to change at line 2766
from the received components in accordance with their local configuration from the received components in accordance with their local configuration
and incoming connection context. This reconstruction is specific to each and incoming connection context. This reconstruction is specific to each
major protocol version. For example, major protocol version. For example,
<xref target="HTTP11" section="3.3"/> defines how a server <xref target="HTTP11" section="3.3"/> defines how a server
determines the target URI of an HTTP/1.1 request. determines the target URI of an HTTP/1.1 request.
</t> </t>
<aside anchor="effective.request.uri"> <aside anchor="effective.request.uri">
<t> <t>
<iref primary="true" item="effective request URI"/> <iref primary="true" item="effective request URI"/>
<strong>Note:</strong> Previous specifications defined the rec omposed target URI as a <strong>Note:</strong> Previous specifications defined the rec omposed target URI as a
distinct concept, the <em>effective request URI</em>. distinct concept, the "effective request URI".
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="field.host" title="Host and :authority"> <section anchor="field.host" title="Host and :authority">
<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
skipping to change at line 3202 skipping to change at line 3199
Some intermediaries include features for transforming messages and their Some intermediaries include features for transforming messages and their
content. A proxy might, for example, convert between image formats in content. A proxy might, for example, convert between image formats in
order to save cache space or to reduce the amount of traffic on a slow order to save cache space or to reduce the amount of traffic on a slow
link. However, operational problems might occur when these transformations link. However, operational problems might occur when these transformations
are applied to content intended for critical applications, such as medical are applied to content intended for critical applications, such as medical
imaging or scientific data analysis, particularly when integrity checks or imaging or scientific data analysis, particularly when integrity checks or
digital signatures are used to ensure that the content received is digital signatures are used to ensure that the content received is
identical to the original. identical to the original.
</t> </t>
<t> <t>
An HTTP-to-HTTP proxy is called a <em>transforming proxy</em> An HTTP-to-HTTP proxy is called a "transforming proxy"
if it is designed or configured to modify messages in a semantically if it is designed or configured to modify messages in a semantically
meaningful way (i.e., modifications, beyond those required by normal meaningful way (i.e., modifications, beyond those required by normal
HTTP processing, that change the message in a way that would be HTTP processing, that change the message in a way that would be
significant to the original sender or potentially significant to significant to the original sender or potentially significant to
downstream recipients). For example, a transforming proxy might be downstream recipients). For example, a transforming proxy might be
acting as a shared annotation server (modifying responses to include acting as a shared annotation server (modifying responses to include
references to a local annotation database), a malware filter, a references to a local annotation database), a malware filter, a
format transcoder, or a privacy filter. Such transformations are presumed format transcoder, or a privacy filter. Such transformations are presumed
to be desired by whichever client (or client organization) chose the to be desired by whichever client (or client organization) chose the
proxy. proxy.
skipping to change at line 3510 skipping to change at line 3507
<section anchor="charset" title="Charset"> <section anchor="charset" title="Charset">
<!-- [rfced] Section 8.3.2. The cross-reference in the sentence below <!-- [rfced] Section 8.3.2. The cross-reference in the sentence below
does not seem to point to the correct section. Please let us know does not seem to point to the correct section. Please let us know
how to update: how to update:
Current: Current:
HTTP uses _charset_ names to indicate or negotiate the character HTTP uses _charset_ names to indicate or negotiate the character
encoding scheme ([RFC6365], Section 1.3) of a textual representation. encoding scheme ([RFC6365], Section 1.3) of a textual representation.
--> -->
<t> <t>
HTTP uses <em>charset</em> names to indicate or negotiate the HTTP uses "charset" names to indicate or negotiate the
character encoding scheme (<xref target="RFC6365" sectionFormat="comma" secti on="1.3"/>) character encoding scheme (<xref target="RFC6365" sectionFormat="comma" secti on="1.3"/>)
of a textual representation. In the fields defined by this document, of a textual representation. In the fields defined by this document,
charset names appear either in parameters (<xref target="field.content-type" format="none">Content-Type</xref>), charset names appear either in parameters (<xref target="field.content-type" format="none">Content-Type</xref>),
or, for <xref target="field.accept-encoding" format="none">Accept-Encoding</x ref>, in the form of a plain <xref target="rule.token.separators" format="none"> token</xref>. or, for <xref target="field.accept-encoding" format="none">Accept-Encoding</x ref>, in the form of a plain <xref target="rule.token.separators" format="none"> token</xref>.
In both cases, charset names are matched case-insensitively. In both cases, charset names are matched case-insensitively.
</t> </t>
<t> <t>
Charset names ought to be registered in the IANA "Character Sets" registry Charset names ought to be registered in the IANA "Character Sets" registry
(<eref target="https://www.iana.org/assignments/character-sets" (<eref target="https://www.iana.org/assignments/character-sets"
brackets="angle"/>) brackets="angle"/>)
skipping to change at line 3956 skipping to change at line 3953
negotiated representations. If the user agent had wanted the latter negotiated representations. If the user agent had wanted the latter
semantics, it would have applied the PUT directly to the Content-Location semantics, it would have applied the PUT directly to the Content-Location
URI. URI.
</t> </t>
</section> </section>
<section anchor="response.validator" title="Validator Fields"> <section anchor="response.validator" title="Validator Fields">
<iref primary="true" item="metadata"/> <iref primary="true" item="metadata"/>
<iref primary="true" item="validator"/> <iref primary="true" item="validator"/>
<iref item="selected representation"/> <iref item="selected representation"/>
<t> <t>
Resource metadata is referred to as a <em>validator</em> if it Resource metadata is referred to as a "validator" if it
can be used within a precondition (<xref target="preconditions"/>) to can be used within a precondition (<xref target="preconditions"/>) to
make a conditional request (<xref target="conditional.requests"/>). make a conditional request (<xref target="conditional.requests"/>).
Validator fields convey a current validator for the Validator fields convey a current validator for the
<xref target="selected.representation" format="none">selected representation< /xref> <xref target="selected.representation" format="none">selected representation< /xref>
(<xref target="representations"/>). (<xref target="representations"/>).
</t> </t>
<t> <t>
In responses to safe requests, validator fields describe the selected In responses to safe requests, validator fields describe the selected
representation chosen by the origin server while handling the response. representation chosen by the origin server while handling the response.
Note that, depending on the method and status code semantics, the Note that, depending on the method and status code semantics, the
skipping to change at line 4005 skipping to change at line 4002
<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
of resource adhere to the same strength of validator, HTTP exposes the of resource adhere to the same strength of validator, HTTP exposes the
type of validator in use and imposes restrictions on when weak validators type of validator in use and imposes restrictions on when weak validators
can be used as preconditions. can be used as preconditions.
</t> </t>
<t> <t>
A <em>strong validator</em> is representation metadata that changes value whe never A "strong validator" is representation metadata that changes value whenever
a change occurs to the representation data that would be observable in the a change occurs to the representation data that would be observable in the
content of a <xref target="status.200" format="none">200 (OK)</xref> response to GET. content of a <xref target="status.200" format="none">200 (OK)</xref> response to GET.
</t> </t>
<t> <t>
A strong validator might change for reasons other than a change to the A strong validator might change for reasons other than a change to the
representation data, such as when a representation data, such as when a
semantically significant part of the representation metadata is changed semantically significant part of the representation metadata is changed
(e.g., <xref target="field.content-type" format="none">Content-Type</xref>), but it is in the best interests of the (e.g., <xref target="field.content-type" format="none">Content-Type</xref>), but it is in the best interests of the
origin server to only change the value when it is necessary to invalidate origin server to only change the value when it is necessary to invalidate
the stored responses held by remote caches and authoring tools. the stored responses held by remote caches and authoring tools.
skipping to change at line 4044 skipping to change at line 4041
function applied to the representation data is also sufficient if the data function applied to the representation data is also sufficient if the data
is available prior to the response header fields being sent and the digest is available prior to the response header fields being sent and the digest
does not need to be recalculated every time a validation request is does not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that differ received. However, if a resource has distinct representations that differ
only in their metadata, such as might occur with content negotiation over only in their metadata, such as might occur with content negotiation over
media types that happen to share the same data format, then the origin media types that happen to share the same data format, then the origin
server needs to incorporate additional information in the validator to server needs to incorporate additional information in the validator to
distinguish those representations. distinguish those representations.
</t> </t>
<t> <t>
In contrast, a <em>weak validator</em> is representation metadata In contrast, a "weak validator" is representation metadata
that might not change for every change to the representation data. This that might not change for every change to the representation data. This
weakness might be due to limitations in how the value is calculated weakness might be due to limitations in how the value is calculated
(e.g., clock resolution), an inability to ensure uniqueness for all (e.g., clock resolution), an inability to ensure uniqueness for all
possible representations of the resource, or a desire of the resource possible representations of the resource, or a desire of the resource
owner to group representations by some self-determined set of owner to group representations by some self-determined set of
equivalency rather than unique sequences of data. equivalency rather than unique sequences of data.
</t> </t>
<t> <t>
An origin server <bcp14>SHOULD</bcp14> change a weak entity-tag whenever it An origin server <bcp14>SHOULD</bcp14> change a weak entity-tag whenever it
considers prior representations to be unacceptable as a substitute for considers prior representations to be unacceptable as a substitute for
skipping to change at line 4296 skipping to change at line 4293
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>
<dt> <dt>
<em>Strong comparison</em>: "Strong comparison":
</dt> </dt>
<dd> <dd>
two entity-tags are equivalent if both are not weak and their opaque-tags two entity-tags are equivalent if both are not weak and their opaque-tags
match character-by-character. match character-by-character.
</dd> </dd>
<dt> <dt>
<em>Weak comparison</em>: "Weak comparison":
</dt> </dt>
<dd> <dd>
two entity-tags are equivalent if their opaque-tags match two entity-tags are equivalent if their opaque-tags match
character-by-character, regardless of either or both being tagged as "weak". character-by-character, regardless of either or both being tagged as "weak".
</dd> </dd>
</dl> </dl>
<t> <t>
The example below shows the results for a set of entity-tag pairs and both The example below shows the results for a set of entity-tag pairs and both
the weak and strong comparison function results: the weak and strong comparison function results:
</t> </t>
skipping to change at line 4551 skipping to change at line 4548
Additional methods, outside the scope of this specification, have been Additional methods, outside the scope of this specification, have been
specified for use in HTTP. All such methods ought to be registered specified for use in HTTP. All such methods ought to be registered
within the "Hypertext Transfer Protocol (HTTP) Method Registry", within the "Hypertext Transfer Protocol (HTTP) Method Registry",
as described in <xref target="method.extensibility"/>. as described in <xref target="method.extensibility"/>.
</t> </t>
</section> </section>
<section anchor="method.properties" title="Common Method Properties"> <section anchor="method.properties" title="Common Method Properties">
<section anchor="safe.methods" title="Safe Methods"> <section anchor="safe.methods" title="Safe Methods">
<iref item="safe" primary="true"/> <iref item="safe" primary="true"/>
<t> <t>
Request methods are considered <em>safe</em> if Request methods are considered "safe" if
their defined semantics are essentially read-only; i.e., the client does their defined semantics are essentially read-only; i.e., the client does
not request, and does not expect, any state change on the origin server not request, and does not expect, any state change on the origin server
as a result of applying a safe method to a target resource. Likewise, as a result of applying a safe method to a target resource. Likewise,
reasonable use of a safe method is not expected to cause any harm, reasonable use of a safe method is not expected to cause any harm,
loss of property, or unusual burden on the origin server. loss of property, or unusual burden on the origin server.
</t> </t>
<t> <t>
This definition of safe methods does not prevent an implementation from This definition of safe methods does not prevent an implementation from
including behavior that is potentially harmful, that is not entirely read-onl y, including behavior that is potentially harmful, that is not entirely read-onl y,
or that causes side effects while invoking a safe method. What is or that causes side effects while invoking a safe method. What is
skipping to change at line 4607 skipping to change at line 4604
the resource owner <bcp14>MUST</bcp14> disable or disallow that action when i t is the resource owner <bcp14>MUST</bcp14> disable or disallow that action when i t is
accessed using a safe request method. Failure to do so will result in accessed using a safe request method. Failure to do so will result in
unfortunate side effects when automated processes perform a GET on unfortunate side effects when automated processes perform a GET on
every URI reference for the sake of link maintenance, pre-fetching, every URI reference for the sake of link maintenance, pre-fetching,
building a search index, etc. building a search index, etc.
</t> </t>
</section> </section>
<section anchor="idempotent.methods" title="Idempotent Methods"> <section anchor="idempotent.methods" title="Idempotent Methods">
<iref item="idempotent" primary="true"/> <iref item="idempotent" primary="true"/>
<t> <t>
A request method is considered A request method is considered "idempotent"
<em>idempotent</em>
if the intended effect on the server of multiple identical requests with if the intended effect on the server of multiple identical requests with
that method is the same as the effect for a single such request. that method is the same as the effect for a single such request.
Of the request methods defined by this Of the request methods defined by this
specification, <xref target="PUT" format="none">PUT</xref>, <xref target="DEL ETE" format="none">DELETE</xref>, and safe request specification, <xref target="PUT" format="none">PUT</xref>, <xref target="DEL ETE" format="none">DELETE</xref>, and safe request
methods are idempotent. methods are idempotent.
</t> </t>
<t> <t>
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each request what has been requested by the user; a server is free to log each request
separately, retain a revision control history, or implement other separately, retain a revision control history, or implement other
skipping to change at line 4914 skipping to change at line 4910
<t> <t>
For example, if the target resource is configured to always have a For example, if the target resource is configured to always have a
<xref target="field.content-type" format="none">Content-Type</xref> of "text/ html" and the representation being PUT <xref target="field.content-type" format="none">Content-Type</xref> of "text/ html" and the representation being PUT
has a Content-Type of "image/jpeg", the origin server ought to do one of: has a Content-Type of "image/jpeg", the origin server ought to do one of:
</t> </t>
<ol type="a"> <ol type="a">
<li>reconfigure the target resource to reflect the new media t ype;</li> <li>reconfigure the target resource to reflect the new media t ype;</li>
<li>transform the PUT representation to a format consistent wi th that <li>transform the PUT representation to a format consistent wi th that
of the resource before saving it as the new resource state; or,</li> of the resource before saving it as the new resource state; or,</li>
<li>reject the request with a <xref target="status.415" format ="none">415 (Unsupported Media Type)</xref> <li>reject the request with a <xref target="status.415" format ="none">415 (Unsupported Media Type)</xref>
response indicating that the target resource is limited to text/html, response indicating that the target resource is limited to "text/html",
perhaps including a link to a different resource that would be a perhaps including a link to a different resource that would be a
suitable target for the new representation.</li> suitable target for the new representation.</li>
</ol> </ol>
<t> <t>
HTTP does not define exactly how a PUT method affects the state HTTP does not define exactly how a PUT method affects the state
of an origin server beyond what can be expressed by the intent of of an origin server beyond what can be expressed by the intent of
the user agent request and the semantics of the origin server response. the user agent request and the semantics of the origin server response.
It does not define what a resource might be, in any sense of that It does not define what a resource might be, in any sense of that
word, beyond the interface provided via HTTP. It does not define word, beyond the interface provided via HTTP. It does not define
how resource state is "stored", nor how such storage might change how resource state is "stored", nor how such storage might change
skipping to change at line 5280 skipping to change at line 5276
(with no defined parameters). (with no defined parameters).
</t> </t>
<t> <t>
A server that receives an Expect field value containing a member other than A server that receives an Expect field value containing a member other than
<xref target="field.expect" format="none">100-continue</xref> <xref target="field.expect" format="none">100-continue</xref>
<bcp14>MAY</bcp14> respond with a <bcp14>MAY</bcp14> respond with a
<xref target="status.417" format="none">417 (Expectation Failed)</xref> statu s code to indicate that the <xref target="status.417" format="none">417 (Expectation Failed)</xref> statu s code to indicate that the
unexpected expectation cannot be met. unexpected expectation cannot be met.
</t> </t>
<t> <t>
A <em>100-continue</em> expectation informs recipients that the A "100-continue" expectation informs recipients that the
client is about to send (presumably large) content in this request client is about to send (presumably large) content in this request
and wishes to receive a <xref target="status.100" format="none">100 (Continue )</xref> interim response if and wishes to receive a <xref target="status.100" format="none">100 (Continue )</xref> interim response if
the method, target URI, and header fields are not sufficient to cause an imme diate the method, target URI, and header fields are not sufficient to cause an imme diate
success, redirect, or error response. This allows the client to wait for an success, redirect, or error response. This allows the client to wait for an
indication that it is worthwhile to send the content before actually indication that it is worthwhile to send the content before actually
doing so, which can improve efficiency when the data is huge or doing so, which can improve efficiency when the data is huge or
when the client anticipates that an error is likely (e.g., when sending a when the client anticipates that an error is likely (e.g., when sending a
state-changing method, for the first time, without previously verified state-changing method, for the first time, without previously verified
authentication credentials). authentication credentials).
</t> </t>
skipping to change at line 6011 skipping to change at line 6007
<!-- [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"/>
<iref item="Realm"/> <iref item="Realm"/>
<iref item="Origin"/> <iref item="Origin"/>
<t> <t>
The <em>realm</em> authentication parameter is reserved for use by The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection. authentication schemes that wish to indicate a scope of protection.
</t> </t>
<t> <t>
A <em>protection space</em> is defined by the origin (see A "protection space" is defined by the origin (see
<xref target="origin"/>) of the <xref target="origin"/>) of the
server being accessed, in combination with the realm value if present. server being accessed, in combination with the realm value if present.
These realms allow the protected resources on a server to be These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, that can have is a string, generally assigned by the origin server, that can have
additional semantics specific to the authentication scheme. Note that a additional semantics specific to the authentication scheme. Note that a
response can have multiple challenges with the same auth-scheme but response can have multiple challenges with the same auth-scheme but
with different realms. with different realms.
</t> </t>
skipping to change at line 6313 skipping to change at line 6309
and over the varying dimensions of content negotiation, and thus the and over the varying dimensions of content negotiation, and thus the
"sameness" of a resource's observed representations over time, is "sameness" of a resource's observed representations over time, is
determined entirely by whatever entity or algorithm selects or generates determined entirely by whatever entity or algorithm selects or generates
those responses. those responses.
</t> </t>
<section anchor="proactive.negotiation" title="Proactive Negotiation"> <section anchor="proactive.negotiation" title="Proactive Negotiation">
<t> <t>
When content negotiation preferences are sent by the user agent in a When content negotiation preferences are sent by the user agent in a
request to encourage an algorithm located at the server to request to encourage an algorithm located at the server to
select the preferred representation, it is called select the preferred representation, it is called
<em>proactive negotiation</em> "proactive negotiation"
(a.k.a., <em>server-driven negotiation</em>). Selection is based on (a.k.a., "server-driven negotiation"). Selection is based on
the available representations for a response (the dimensions over which it the available representations for a response (the dimensions over which it
might vary, such as language, content coding, etc.) compared to various might vary, such as language, content coding, etc.) compared to various
information supplied in the request, including both the explicit information supplied in the request, including both the explicit
negotiation header fields below and implicit negotiation header fields below and implicit
characteristics, such as the client's network address or parts of the characteristics, such as the client's network address or parts of the
<xref target="field.user-agent" format="none">User-Agent</xref> field. <xref target="field.user-agent" format="none">User-Agent</xref> field.
</t> </t>
<t> <t>
Proactive negotiation is advantageous when the algorithm for Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to selecting from among the available representations is difficult to
skipping to change at line 6383 skipping to change at line 6379
in <xref target="proactive.negotiation" format="none">proactive negotiation</ xref> of the response content. in <xref target="proactive.negotiation" format="none">proactive negotiation</ xref> of the response content.
The preferences sent in these The preferences sent in these
fields apply to any content in the response, including representations of fields apply to any content in the response, including representations of
the target resource, representations of error or processing status, and the target resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear within potentially even the miscellaneous text strings that might appear within
the protocol. the protocol.
</t> </t>
</section> </section>
<section anchor="reactive.negotiation" title="Reactive Negotiation"> <section anchor="reactive.negotiation" title="Reactive Negotiation">
<t> <t>
With <em>reactive negotiation</em> With "reactive negotiation" (a.k.a., "agent-driven negotiation"), selection o
(a.k.a., <em>agent-driven negotiation</em>), selection of f
content (regardless of the status code) is performed by content (regardless of the status code) is performed by
the user agent after receiving an initial response. The mechanism for the user agent after receiving an initial response. The mechanism for
reactive negotiation might be as simple as a list of references to reactive negotiation might be as simple as a list of references to
alternative representations. alternative representations.
</t> </t>
<t> <t>
If the user agent is not satisfied by the initial response content, If the user agent is not satisfied by the initial response content,
it can perform a GET request on one or more of the alternative resources it can perform a GET request on one or more of the alternative resources
to obtain a different representation. Selection of such alternatives might to obtain a different representation. Selection of such alternatives might
be performed automatically (by the user agent) or manually (e.g., by the be performed automatically (by the user agent) or manually (e.g., by the
skipping to change at line 6426 skipping to change at line 6421
latency if transmitted in the header section, and needing a second request latency if transmitted in the header section, and needing a second request
to obtain an alternate representation. Furthermore, this specification to obtain an alternate representation. Furthermore, this specification
does not define a mechanism for supporting automatic selection, though it does not define a mechanism for supporting automatic selection, though it
does not prevent such a mechanism from being developed. does not prevent such a mechanism from being developed.
</t> </t>
</section> </section>
<section anchor="request.content.negotiation" <section anchor="request.content.negotiation"
title="Request Content Negotiation"> title="Request Content Negotiation">
<t> <t>
When content negotiation preferences are sent in a server's response, the When content negotiation preferences are sent in a server's response, the
listed preferences are called <em>request content negotiation</em> listed preferences are called "request content negotiation"
because they intend to influence selection of an appropriate content for because they intend to influence selection of an appropriate content for
subsequent requests to that resource. For example, subsequent requests to that resource. For example,
the <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) and the <xref target="field.accept" format="none">Accept</xref> (<xref target="fi eld.accept"/>) and
<xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>) <xref target="field.accept-encoding" format="none">Accept-Encoding</xref> (<x ref target="field.accept-encoding"/>)
header fields can be sent in a response to indicate preferred media types header fields can be sent in a response to indicate preferred media types
and content codings for subsequent requests to that resource. and content codings for subsequent requests to that resource.
</t> </t>
<t> <t>
Similarly, <xref target="RFC5789" section="3.1"/> defines Similarly, <xref target="RFC5789" section="3.1"/> defines
the "Accept-Patch" response header field, which allows discovery of the "Accept-Patch" response header field, which allows discovery of
skipping to change at line 7695 skipping to change at line 7690
<section anchor="range.units" title="Range Units"> <section anchor="range.units" title="Range Units">
<t> <t>
Representation data can be partitioned into subranges when there are Representation data can be partitioned into subranges when there are
addressable structural units inherent to that data's content coding or addressable structural units inherent to that data's content coding or
media type. For example, octet (a.k.a. byte) boundaries are a structural media type. For example, octet (a.k.a. byte) boundaries are a structural
unit common to all representation data, allowing partitions of the data to unit common to all representation data, allowing partitions of the data to
be identified as a range of bytes at some offset from the start or end of be identified as a range of bytes at some offset from the start or end of
that data. that data.
</t> </t>
<t> <t>
This general notion of a <em>range unit</em> is used This general notion of a "range unit" is used
in the <xref target="field.accept-ranges" format="none">Accept-Ranges</xref> (<xref target="field.accept-ranges"/>) in the <xref target="field.accept-ranges" format="none">Accept-Ranges</xref> (<xref target="field.accept-ranges"/>)
response header field to advertise support for range requests, the response header field to advertise support for range requests, the
<xref target="field.range" format="none">Range</xref> (<xref target="field.ra nge"/>) request header field <xref target="field.range" format="none">Range</xref> (<xref target="field.ra nge"/>) request header field
to delineate the parts of a representation that are requested, and the to delineate the parts of a representation that are requested, and the
<xref target="field.content-range" format="none">Content-Range</xref> (<xref target="field.content-range"/>) <xref target="field.content-range" format="none">Content-Range</xref> (<xref target="field.content-range"/>)
header field to describe which part of a representation is being header field to describe which part of a representation is being
transferred. transferred.
</t> </t>
<iref primary="true" item="Grammar" subitem="range-unit"/> <iref primary="true" item="Grammar" subitem="range-unit"/>
<sourcecode type="abnf9110"><![CDATA[ range-unit = token <sourcecode type="abnf9110"><![CDATA[ range-unit = token
skipping to change at line 8207 skipping to change at line 8202
<section anchor="multipart.byteranges" title="Media Type multipart/byte ranges"> <section anchor="multipart.byteranges" title="Media Type multipart/byte ranges">
<iref item="Media Type" subitem="multipart/byteranges" primary="true "/> <iref item="Media Type" subitem="multipart/byteranges" primary="true "/>
<iref item="multipart/byteranges Media Type" primary="true"/> <iref item="multipart/byteranges Media Type" primary="true"/>
<t> <t>
When a <xref target="status.206" format="none">206 (Partial Content)</xref> r esponse message includes the When a <xref target="status.206" format="none">206 (Partial Content)</xref> r esponse message includes the
content of multiple ranges, they are transmitted as body parts in a content of multiple ranges, they are transmitted as body parts in a
multipart message body (<xref target="RFC2046" sectionFormat="comma" section= "5.1"/>) multipart message body (<xref target="RFC2046" sectionFormat="comma" section= "5.1"/>)
with the media type of "multipart/byteranges". with the media type of "multipart/byteranges".
</t> </t>
<t> <t>
The multipart/byteranges media type includes one or more body parts, each The "multipart/byteranges" media type includes one or more body parts, each
with its own <xref target="field.content-type" format="none">Content-Type</xr ef> and <xref target="field.content-range" format="none">Content-Range</xref> with its own <xref target="field.content-type" format="none">Content-Type</xr ef> and <xref target="field.content-range" format="none">Content-Range</xref>
fields. The required boundary parameter specifies the boundary string used fields. The required boundary parameter specifies the boundary string used
to separate each body part. to separate each body part.
</t> </t>
<t> <t>
Implementation Notes: Implementation Notes:
</t> </t>
<ol> <ol>
<li>Additional CRLFs might precede the first boundary string in t he body.</li> <li>Additional CRLFs might precede the first boundary string in t he body.</li>
<li>Although <xref target="RFC2046"/> permits the boundary string to be <li>Although <xref target="RFC2046"/> permits the boundary string to be
quoted, some existing implementations handle a quoted boundary quoted, some existing implementations handle a quoted boundary
string incorrectly.</li> string incorrectly.</li>
<li>A number of clients and servers were coded to an early draft <li>A number of clients and servers were coded to an early draft
of the byteranges specification that used a media type of of the byteranges specification that used a media type of
"multipart/x-byteranges"<iref item="multipart/x-byteranges Media Type"/><i ref item="Media Type" subitem="multipart/x-byteranges"/>, "multipart/x-byteranges"<iref item="multipart/x-byteranges Media Type"/><i ref item="Media Type" subitem="multipart/x-byteranges"/>,
which is almost (but not quite) compatible with this type.</li> which is almost (but not quite) compatible with this type.</li>
</ol> </ol>
<t> <t>
Despite the name, the multipart/byteranges media type is not limited to Despite the name, the "multipart/byteranges" media type is not limited to
byte ranges. The following example uses an "exampleunit" range unit: byte ranges. The following example uses an "exampleunit" range unit:
</t> </t>
<sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Conten t <sourcecode type="http-message"><![CDATA[HTTP/1.1 206 Partial Conten t
Date: Tue, 14 Nov 1995 06:25:24 GMT Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785 Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-Type: video/example Content-Type: video/example
skipping to change at line 8371 skipping to change at line 8366
three-digit integer values outside of that range (i.e., 600..999) for three-digit integer values outside of that range (i.e., 600..999) for
internal communication of non-HTTP status (e.g., library errors). A client internal communication of non-HTTP status (e.g., library errors). A client
that receives a response with an invalid status code <bcp14>SHOULD</bcp14> pr ocess the that receives a response with an invalid status code <bcp14>SHOULD</bcp14> pr ocess the
response as if it had a <xref target="status.5xx" format="none">5xx (Server E rror)</xref> status code. response as if it had a <xref target="status.5xx" format="none">5xx (Server E rror)</xref> status code.
</t> </t>
<t anchor="final.interim"> <t anchor="final.interim">
<iref item="Status Codes" subitem="Final"/> <iref item="Status Codes" subitem="Final"/>
<iref item="Status Codes" subitem="Interim"/> <iref item="Status Codes" subitem="Interim"/>
<iref item="Status Codes" subitem="Informational"/> <iref item="Status Codes" subitem="Informational"/>
A single request can have multiple associated responses: zero or more A single request can have multiple associated responses: zero or more
<em>interim</em> (non-final) responses with status codes in the "interim" (non-final) responses with status codes in the
"informational" (<xref target="status.1xx" format="none">1xx</xref>) range, fo llowed by exactly one "informational" (<xref target="status.1xx" format="none">1xx</xref>) range, fo llowed by exactly one
<em>final</em> response with a status code in one of the other ranges. "final" response with a status code in one of the other ranges.
</t> </t>
<section anchor="overview.of.status.codes" title="Overview of Status Co des"> <section anchor="overview.of.status.codes" title="Overview of Status Co des">
<t> <t>
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
skipping to change at line 8402 skipping to change at line 8397
within the "Hypertext Transfer Protocol (HTTP) Status Code Registry", within the "Hypertext Transfer Protocol (HTTP) Status Code Registry",
as described in <xref target="status.code.extensibility"/>. as described in <xref target="status.code.extensibility"/>.
</t> </t>
</section> </section>
<section anchor="status.1xx" title="Informational 1xx"> <section anchor="status.1xx" title="Informational 1xx">
<iref primary="true" item="1xx Informational (status code class)"/> <iref primary="true" item="1xx Informational (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="1xx Informational"/> subitem="1xx Informational"/>
<t> <t>
The <em>1xx (Informational)</em> class of status code indicates an The "1xx (Informational)" class of status code indicates an
interim response for communicating connection status or request progress interim response for communicating connection status or request progress
prior to completing the requested action and sending a final response. prior to completing the requested action and sending a final response.
Since HTTP/1.0 did not define any 1xx status codes, a server <bcp14>MUST NOT< /bcp14> send Since HTTP/1.0 did not define any 1xx status codes, a server <bcp14>MUST NOT< /bcp14> send
a 1xx response to an HTTP/1.0 client. a 1xx response to an HTTP/1.0 client.
</t> </t>
<t> <t>
A 1xx response is terminated by the end of the header section; A 1xx 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>
skipping to change at line 8427 skipping to change at line 8422
<t> <t>
A proxy <bcp14>MUST</bcp14> forward 1xx responses unless the proxy itself A proxy <bcp14>MUST</bcp14> forward 1xx responses unless the proxy itself
requested the generation of the 1xx response. For example, if a requested the generation of the 1xx response. For example, if a
proxy adds an "Expect: 100-continue" header field when it forwards a request, proxy adds an "Expect: 100-continue" header field when it forwards a request,
then it need not forward the corresponding <xref target="status.100" format=" none">100 (Continue)</xref> then it need not forward the corresponding <xref target="status.100" format=" none">100 (Continue)</xref>
response(s). response(s).
</t> </t>
<section anchor="status.100" title="100 Continue"> <section anchor="status.100" title="100 Continue">
<iref primary="true" item="100 Continue (status code)"/> <iref primary="true" item="100 Continue (status code)"/>
<t> <t>
The <em>100 (Continue)</em> status code indicates that the initial The "100 (Continue)" status code indicates that the initial
part of a request has been received and has not yet been rejected by the part of a request has been received and has not yet been rejected by the
server. The server intends to send a final response after the request has server. The server intends to send a final response after the request has
been fully received and acted upon. been fully received and acted upon.
</t> </t>
<t> <t>
When the request contains an <xref target="field.expect" format="none">Expect </xref> header field that When the request contains an <xref target="field.expect" format="none">Expect </xref> header field that
includes a <xref target="field.expect" format="none">100-continue</xref> expe ctation, the 100 response includes a <xref target="field.expect" format="none">100-continue</xref> expe ctation, the 100 response
indicates that the server wishes to receive the request content, indicates that the server wishes to receive the request content,
as described in <xref target="field.expect"/>. The client as described in <xref target="field.expect"/>. The client
ought to continue sending the request and discard the 100 response. ought to continue sending the request and discard the 100 response.
</t> </t>
<t> <t>
If the request did not contain an <xref target="field.expect" format="none">E xpect</xref> header field If the request did not contain an <xref target="field.expect" format="none">E xpect</xref> header field
containing the <xref target="field.expect" format="none">100-continue</xref> expectation, containing the <xref target="field.expect" format="none">100-continue</xref> expectation,
the client can simply discard this interim response. the client can simply discard this interim response.
</t> </t>
</section> </section>
<section anchor="status.101" title="101 Switching Protocols"> <section anchor="status.101" title="101 Switching Protocols">
<iref primary="true" item="101 Switching Protocols (status code)" /> <iref primary="true" item="101 Switching Protocols (status code)" />
<t> <t>
The <em>101 (Switching Protocols)</em> status code indicates that the The "101 (Switching Protocols)" status code indicates that the
server understands and is willing to comply with the client's request, server understands and is willing to comply with the client's request,
via the <xref target="field.upgrade" format="none">Upgrade</xref> header fiel d (<xref target="field.upgrade"/>), for via the <xref target="field.upgrade" format="none">Upgrade</xref> header fiel d (<xref target="field.upgrade"/>), for
a change in the application protocol being used on this connection. a change in the application protocol being used on this connection.
The server <bcp14>MUST</bcp14> generate an Upgrade header field in the respon se that The server <bcp14>MUST</bcp14> generate an Upgrade header field in the respon se that
indicates which protocol(s) will be in effect after this response. indicates which protocol(s) will be in effect after this response.
</t> </t>
<t> <t>
It is assumed that the server will only agree to switch protocols when It is assumed that the server will only agree to switch protocols when
it is advantageous to do so. For example, switching to a newer version of it is advantageous to do so. For example, switching to a newer version of
HTTP might be advantageous over older versions, and switching to a HTTP might be advantageous over older versions, and switching to a
real-time, synchronous protocol might be advantageous when delivering real-time, synchronous protocol might be advantageous when delivering
resources that use such features. resources that use such features.
</t> </t>
</section> </section>
</section> </section>
<section anchor="status.2xx" title="Successful 2xx"> <section anchor="status.2xx" title="Successful 2xx">
<iref primary="true" item="2xx Successful (status code class)"/> <iref primary="true" item="2xx Successful (status code class)"/>
<iref primary="true" item="Status Codes Classes" subitem="2xx Succes sful"/> <iref primary="true" item="Status Codes Classes" subitem="2xx Succes sful"/>
<t> <t>
The <em>2xx (Successful)</em> class of status code indicates that The "2xx (Successful)" class of status code indicates that
the client's request was successfully received, understood, and accepted. the client's request was successfully received, understood, and accepted.
</t> </t>
<section anchor="status.200" title="200 OK"> <section anchor="status.200" title="200 OK">
<iref primary="true" item="200 OK (status code)"/> <iref primary="true" item="200 OK (status code)"/>
<t> <t>
The <em>200 (OK)</em> status code indicates that the request has The "200 (OK)" status code indicates that the request has
succeeded. The content sent in a 200 response depends on the request succeeded. The content sent in a 200 response depends on the request
method. For the methods defined by this specification, the intended meaning method. For the methods defined by this specification, the intended meaning
of the content can be summarized as: of the content can be summarized as:
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th>Request Method</th> <th>Request Method</th>
<th>Response content is a representation of:</th> <th>Response content is a representation of:</th>
skipping to change at line 8522 skipping to change at line 8517
<td>the request message as received by the server return ing the <td>the request message as received by the server return ing the
trace</td> trace</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
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. 204 (No Content) response instead.
For CONNECT, there is no content because the successful result is a For CONNECT, there is no content because the successful result is a
tunnel, which begins immediately after the 200 response header section. tunnel, which begins immediately after the 200 response header section.
</t> </t>
<t> <t>
A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y A 200 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
<t> <t>
In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any In 200 responses to GET or HEAD, an origin server <bcp14>SHOULD</bcp14> send any
available validator fields (<xref target="response.validator"/>) for the available validator fields (<xref target="response.validator"/>) for the
skipping to change at line 8548 skipping to change at line 8543
(<xref target="response.validator"/>) sent in the response convey the (<xref target="response.validator"/>) sent in the response convey the
current validators for the new representation formed as a result of current validators for the new representation formed as a result of
successfully applying the request semantics. Note that the PUT method successfully applying the request semantics. Note that the PUT method
(<xref target="PUT"/>) has additional requirements that might preclude (<xref target="PUT"/>) has additional requirements that might preclude
sending such validators. sending such validators.
</t> </t>
</section> </section>
<section anchor="status.201" title="201 Created"> <section anchor="status.201" title="201 Created">
<iref primary="true" item="201 Created (status code)"/> <iref primary="true" item="201 Created (status code)"/>
<t> <t>
The <em>201 (Created)</em> status code indicates that the request has The "201 (Created)" status code indicates that the request has
been fulfilled and has resulted in one or more new resources being created. been fulfilled and has resulted in one or more new resources being created.
The primary resource created by the request is identified by either a The primary resource created by the request is identified by either a
<xref target="field.location" format="none">Location</xref> header field in t he response or, if no <xref target="field.location" format="none">Location</xref> header field in t he response or, if no
<xref target="field.location" format="none">Location</xref> header field is r eceived, by the target URI. <xref target="field.location" format="none">Location</xref> header field is r eceived, by the target URI.
</t> </t>
<t> <t>
The 201 response content typically describes and links to the resource(s) The 201 response content typically describes and links to the resource(s)
created. Any validator fields (<xref target="response.validator"/>) created. Any validator fields (<xref target="response.validator"/>)
sent in the response convey the current validators for a new sent in the response convey the current validators for a new
representation created by the request. Note that the PUT method representation created by the request. Note that the PUT method
(<xref target="PUT"/>) has additional requirements that might preclude (<xref target="PUT"/>) has additional requirements that might preclude
sending such validators. sending such validators.
</t> </t>
</section> </section>
<section anchor="status.202" title="202 Accepted"> <section anchor="status.202" title="202 Accepted">
<iref primary="true" item="202 Accepted (status code)"/> <iref primary="true" item="202 Accepted (status code)"/>
<t> <t>
The <em>202 (Accepted)</em> status code indicates that the request The "202 (Accepted)" status code indicates that the request
has been accepted for processing, but the processing has not been has been accepted for processing, but the processing has not been
completed. The request might or might not eventually be acted upon, as it completed. The request might or might not eventually be acted upon, as it
might be disallowed when processing actually takes place. There is no might be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
</t> </t>
<t> <t>
The 202 response is intentionally noncommittal. Its purpose is to The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an estimate of (or embed) a status monitor that can provide the user with an estimate of
when the request will be fulfilled. when the request will be fulfilled.
</t> </t>
</section> </section>
<section anchor="status.203" title="203 Non-Authoritative Informatio n"> <section anchor="status.203" title="203 Non-Authoritative Informatio n">
<iref primary="true" item="203 Non-Authoritative Information (sta tus code)"/> <iref primary="true" item="203 Non-Authoritative Information (sta tus code)"/>
<t> <t>
The <em>203 (Non-Authoritative Information)</em> status code The "203 (Non-Authoritative Information)" status code
indicates that the request was successful but the enclosed content has been indicates that the request was successful but the enclosed content has been
modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response modified from that of the origin server's <xref target="status.200" format="n one">200 (OK)</xref> response
by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the by a transforming proxy (<xref target="message.transformations"/>). This stat us code allows the
proxy to notify recipients when a transformation has been applied, since proxy to notify recipients when a transformation has been applied, since
that knowledge might impact later decisions regarding the content. For that knowledge might impact later decisions regarding the content. For
example, future cache validation requests for the content might only be example, future cache validation requests for the content might only be
applicable along the same request path (through the same proxies). applicable along the same request path (through the same proxies).
</t> </t>
<t> <t>
A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y A 203 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.204" title="204 No Content"> <section anchor="status.204" title="204 No Content">
<iref primary="true" item="204 No Content (status code)"/> <iref primary="true" item="204 No Content (status code)"/>
<t> <t>
The <em>204 (No Content)</em> status code indicates that the server The "204 (No Content)" status code indicates that the server
has successfully fulfilled the request and that there is no additional has successfully fulfilled the request and that there is no additional
content to send in the response content. Metadata in the response content to send in the response content. Metadata in the response
header fields refer to the <xref target="target.resource" format="none">targe t resource</xref> and its header fields refer to the <xref target="target.resource" format="none">targe t resource</xref> and its
<xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied. <xref target="selected.representation" format="none">selected representation< /xref> after the requested action was applied.
</t> </t>
<t> <t>
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
request and the response contains an <xref target="field.etag" format="none"> ETag</xref> field, then request and the response contains an <xref target="field.etag" format="none"> ETag</xref> field, then
the PUT was successful and the ETag field value contains the entity-tag for the PUT was successful and the ETag field value contains the entity-tag for
the new representation of that target resource. the new representation of that target resource.
skipping to change at line 8644 skipping to change at line 8639
it cannot contain content or trailers. it cannot contain content or trailers.
</t> </t>
<t> <t>
A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y A 204 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.205" title="205 Reset Content"> <section anchor="status.205" title="205 Reset Content">
<iref primary="true" item="205 Reset Content (status code)"/> <iref primary="true" item="205 Reset Content (status code)"/>
<t> <t>
The <em>205 (Reset Content)</em> status code indicates that the The "205 (Reset Content)" 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>
<t> <t>
This response is intended to support a common data entry use case where This response is intended to support a common data entry use case where
the user receives content that supports data entry (a form, notepad, the user receives content that supports data entry (a form, notepad,
canvas, etc.), enters or manipulates data in that space, causes the entered canvas, etc.), enters or manipulates data in that space, causes the entered
data to be submitted in a request, and then the data entry mechanism is data to be submitted in a request, and then the data entry mechanism is
reset for the next entry so that the user can easily initiate another reset for the next entry so that the user can easily initiate another
input action. input action.
</t> </t>
<t> <t>
Since the 205 status code implies that no additional content will be Since the 205 status code implies that no additional content will be
provided, a server <bcp14>MUST NOT</bcp14> generate content in a 205 response . provided, a server <bcp14>MUST NOT</bcp14> generate content in a 205 response .
</t> </t>
</section> </section>
<section anchor="status.206" title="206 Partial Content"> <section anchor="status.206" title="206 Partial Content">
<iref primary="true" item="206 Partial Content (status code)"/> <iref primary="true" item="206 Partial Content (status code)"/>
<t> <t>
The <em>206 (Partial Content)</em> status code indicates that the The "206 (Partial Content)" status code indicates that the
server is successfully fulfilling a range request for the target resource server is successfully fulfilling a range request for the target resource
by transferring one or more parts of the by transferring one or more parts of the
<xref target="selected.representation" format="none">selected representation< /xref>. <xref target="selected.representation" format="none">selected representation< /xref>.
</t> </t>
<t> <t>
A server that supports range requests (<xref target="range.requests"/>) will A server that supports range requests (<xref target="range.requests"/>) will
usually attempt to satisfy all of the requested ranges, since sending usually attempt to satisfy all of the requested ranges, since sending
less data will likely result in another client request for the remainder. less data will likely result in another client request for the remainder.
However, a server might want to send only a subset of the data requested However, a server might want to send only a subset of the data requested
for reasons of its own, such as temporary unavailability, cache efficiency, for reasons of its own, such as temporary unavailability, cache efficiency,
skipping to change at line 8787 skipping to change at line 8782
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
]]></sourcecode> ]]></sourcecode>
<t> <t>
When multiple ranges are requested, a server <bcp14>MAY</bcp14> coalesce any of the When multiple ranges are requested, a server <bcp14>MAY</bcp14> coalesce any of the
ranges that overlap, or that are separated by a gap that is smaller than the ranges that overlap, or that are separated by a gap that is smaller than the
overhead of sending multiple parts, regardless of the order in which the overhead of sending multiple parts, regardless of the order in which the
corresponding range-spec appeared in the received <xref target="field.range" format="none">Range</xref> corresponding range-spec appeared in the received <xref target="field.range" format="none">Range</xref>
header field. Since the typical overhead between each part of a header field. Since the typical overhead between each part of a
multipart/byteranges is around 80 bytes, depending on the selected "multipart/byteranges" is around 80 bytes, depending on the selected
representation's media type and the chosen boundary parameter length, it representation's media type and the chosen boundary parameter length, it
can be less efficient to transfer many small disjoint parts than it is to can be less efficient to transfer many small disjoint parts than it is to
transfer the entire selected representation. transfer the entire selected representation.
</t> </t>
<t> <t>
A server <bcp14>MUST NOT</bcp14> generate a multipart response to a request f or a single A server <bcp14>MUST NOT</bcp14> generate a multipart response to a request f or a single
range, since a client that does not request multiple parts might not range, since a client that does not request multiple parts might not
support multipart responses. However, a server <bcp14>MAY</bcp14> generate a support multipart responses. However, a server <bcp14>MAY</bcp14> generate a
multipart/byteranges response with only a single body part if multiple "multipart/byteranges" response with only a single body part if multiple
ranges were requested and only one range was found to be satisfiable or ranges were requested and only one range was found to be satisfiable or
only one range remained after coalescing. only one range remained after coalescing.
A client that cannot process a multipart/byteranges response <bcp14>MUST NOT< /bcp14> A client that cannot process a multipart/byteranges response <bcp14>MUST NOT< /bcp14>
generate a request that asks for multiple ranges. generate a request that asks for multiple ranges.
</t> </t>
<t> <t>
A server that generates a multipart response <bcp14>SHOULD</bcp14> send A server that generates a multipart response <bcp14>SHOULD</bcp14> send
the parts in the same order that the corresponding range-spec appeared the parts in the same order that the corresponding range-spec appeared
in the received <xref target="field.range" format="none">Range</xref> header field, excluding those ranges in the received <xref target="field.range" format="none">Range</xref> header field, excluding those ranges
that were deemed unsatisfiable or that were coalesced into other ranges. that were deemed unsatisfiable or that were coalesced into other ranges.
skipping to change at line 8871 skipping to change at line 8866
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="status.3xx" title="Redirection 3xx"> <section anchor="status.3xx" title="Redirection 3xx">
<iref primary="true" item="3xx Redirection (status code class)"/> <iref primary="true" item="3xx Redirection (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="3xx Redirection"/> subitem="3xx Redirection"/>
<t> <t>
The <em>3xx (Redirection)</em> class of status code indicates that The "3xx (Redirection)" class of status code indicates that
further action needs to be taken by the user agent in order to fulfill the further action needs to be taken by the user agent in order to fulfill the
request. There are several types of redirects: request. There are several types of redirects:
</t> </t>
<ol> <ol>
<li> <li>
Redirects that indicate this resource might be available at a Redirects that indicate this resource might be available at a
different URI, as provided by the <xref target="field.location" format="none ">Location</xref> header field, different URI, as provided by the <xref target="field.location" format="none ">Location</xref> header field,
as in the status codes <xref target="status.301" format="none">301 (Moved Pe rmanently)</xref>, as in the status codes <xref target="status.301" format="none">301 (Moved Pe rmanently)</xref>,
<xref target="status.302" format="none">302 (Found)</xref>, <xref target="st atus.307" format="none">307 (Temporary Redirect)</xref>, and <xref target="status.302" format="none">302 (Found)</xref>, <xref target="st atus.307" format="none">307 (Temporary Redirect)</xref>, and
<xref target="status.308" format="none">308 (Permanent Redirect)</xref>. <xref target="status.308" format="none">308 (Permanent Redirect)</xref>.
skipping to change at line 9018 skipping to change at line 9013
<t> <t>
<strong>Note:</strong> An earlier version of this specificatio n recommended a <strong>Note:</strong> An earlier version of this specificatio n recommended a
maximum of five redirections (<xref target="RFC2068" sectionFormat="comma" s ection="10.3"/>). maximum of five redirections (<xref target="RFC2068" sectionFormat="comma" s ection="10.3"/>).
Content developers need to be aware that some clients might Content developers need to be aware that some clients might
implement such a fixed limitation. implement such a fixed limitation.
</t> </t>
</aside> </aside>
<section anchor="status.300" title="300 Multiple Choices"> <section anchor="status.300" title="300 Multiple Choices">
<iref primary="true" item="300 Multiple Choices (status code)"/> <iref primary="true" item="300 Multiple Choices (status code)"/>
<t> <t>
The <em>300 (Multiple Choices)</em> status code indicates that the The "300 (Multiple Choices)" status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has more than one representation, each with <xref target="target.resource" format="none">target resource</xref> has more than one representation, each with
its own more specific identifier, and information about the alternatives is its own more specific identifier, and information about the alternatives is
being provided so that the user (or user agent) can select a preferred being provided so that the user (or user agent) can select a preferred
representation by redirecting its request to one or more of those representation by redirecting its request to one or more of those
identifiers. In other words, the server desires that the user agent engage identifiers. In other words, the server desires that the user agent engage
in reactive negotiation to select the most appropriate representation(s) in reactive negotiation to select the most appropriate representation(s)
for its needs (<xref target="content.negotiation"/>). for its needs (<xref target="content.negotiation"/>).
</t> </t>
<t> <t>
If the server has a preferred choice, the server <bcp14>SHOULD</bcp14> genera te a If the server has a preferred choice, the server <bcp14>SHOULD</bcp14> genera te a
skipping to change at line 9065 skipping to change at line 9060
led to both URI and Alternates (a subsequent proposal) being dropped from led to both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list as a this specification. It is possible to communicate the list as a
Link header field value <xref target="RFC8288"/> whose members have a relatio nship of Link header field value <xref target="RFC8288"/> whose members have a relatio nship of
"alternate", though deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.301" title="301 Moved Permanently"> <section anchor="status.301" title="301 Moved Permanently">
<iref primary="true" item="301 Moved Permanently (status code)"/> <iref primary="true" item="301 Moved Permanently (status code)"/>
<t> <t>
The <em>301 (Moved Permanently)</em> status code indicates that the The "301 (Moved Permanently)" status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and <xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and
any future references to this resource ought to use one of the enclosed any future references to this resource ought to use one of the enclosed
URIs. The server is suggesting that a user agent with link-editing capability URIs. The server is suggesting that a user agent with link-editing capability
can permanently replace references to the target URI with one of the can permanently replace references to the target URI with one of the
new references sent by the server. However, this suggestion is usually new references sent by the server. However, this suggestion is usually
ignored unless the user agent is actively editing references ignored unless the user agent is actively editing references
(e.g., engaged in authoring content), the connection is secured, and (e.g., engaged in authoring content), the connection is secured, and
the origin server is a trusted authority for the content being edited. the origin server is a trusted authority for the content being edited.
</t> </t>
<t> <t>
skipping to change at line 9098 skipping to change at line 9093
</t> </t>
</aside> </aside>
<t> <t>
A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y A 301 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.302" title="302 Found"> <section anchor="status.302" title="302 Found">
<iref primary="true" item="302 Found (status code)"/> <iref primary="true" item="302 Found (status code)"/>
<t> <t>
The <em>302 (Found)</em> status code indicates that the target The "302 (Found)" 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>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the
response containing a URI reference for the different URI. response containing a URI reference for the different 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 different URI(s). a hyperlink to the different URI(s).
skipping to change at line 9122 skipping to change at line 9117
<strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the <strong>Note:</strong> For historical reasons, a user agent <bcp14>MAY</bcp14> change the
request method from POST to GET for the subsequent request. If this request method from POST to GET for the subsequent request. If this
behavior is undesired, the <xref target="status.307" format="none">307 (Temp orary Redirect)</xref> behavior is undesired, the <xref target="status.307" format="none">307 (Temp orary Redirect)</xref>
status code can be used instead. status code can be used instead.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.303" title="303 See Other"> <section anchor="status.303" title="303 See Other">
<iref primary="true" item="303 See Other (status code)"/> <iref primary="true" item="303 See Other (status code)"/>
<t> <t>
The <em>303 (See Other)</em> status code indicates that the server is The "303 (See Other)" status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a URI redirecting the user agent to a different resource, as indicated by a URI
in the <xref target="field.location" format="none">Location</xref> header fie ld, which is intended to provide in the <xref target="field.location" format="none">Location</xref> header fie ld, which is intended to provide
an indirect response to the original request. A user agent can perform a an indirect response to the original request. A user agent can perform a
retrieval request targeting that URI (a GET or HEAD request if using HTTP), retrieval request targeting that URI (a GET or HEAD request if using HTTP),
which might also be redirected, and present the eventual result as an which might also be redirected, and present the eventual result as an
answer to the original request. Note that the new URI in the Location answer to the original request. Note that the new URI in the Location
header field is not considered equivalent to the target URI. header field is not considered equivalent to the target URI.
</t> </t>
<t> <t>
This status code is applicable to any HTTP method. It is This status code is applicable to any HTTP method. It is
skipping to change at line 9159 skipping to change at line 9154
</t> </t>
<t> <t>
Except for responses to a HEAD request, the representation of a 303 Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to the response ought to contain a short hypertext note with a hyperlink to the
same URI reference provided in the <xref target="field.location" format="none ">Location</xref> header field. same URI reference provided in the <xref target="field.location" format="none ">Location</xref> header field.
</t> </t>
</section> </section>
<section anchor="status.304" title="304 Not Modified"> <section anchor="status.304" title="304 Not Modified">
<iref primary="true" item="304 Not Modified (status code)"/> <iref primary="true" item="304 Not Modified (status code)"/>
<t> <t>
The <em>304 (Not Modified)</em> status code indicates that a The "304 (Not Modified)" status code indicates that a
conditional GET or HEAD request has been conditional GET or HEAD request has been
received and would have resulted in a <xref target="status.200" format="none" >200 (OK)</xref> response received and would have resulted in a <xref target="status.200" format="none" >200 (OK)</xref> response
if it were not for the fact that the condition evaluated to false. if it were not for the fact that the condition evaluated to false.
In other words, there is no need for the server to transfer a In other words, there is no need for the server to transfer a
representation of the target resource because the request indicates that representation of the target resource because the request indicates that
the client, which made the request conditional, already has a valid the client, which made the request conditional, already has a valid
representation; the server is therefore redirecting the client to make representation; the server is therefore redirecting the client to make
use of that stored representation as if it were the content of a use of that stored representation as if it were the content of a
<xref target="status.200" format="none">200 (OK)</xref> response. <xref target="status.200" format="none">200 (OK)</xref> response.
</t> </t>
skipping to change at line 9214 skipping to change at line 9209
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">
<iref primary="true" item="305 Use Proxy (status code)"/> <iref primary="true" item="305 Use Proxy (status code)"/>
<t> <t>
The <em>305 (Use Proxy)</em> status code was defined in a previous The "305 (Use Proxy)" status code was defined in a previous
version of this specification and is now deprecated (<xref target="RFC7231" s ection="B"/>). version of this specification and is now deprecated (<xref target="RFC7231" s ection="B"/>).
</t> </t>
</section> </section>
<section anchor="status.306" title="306 (Unused)"> <section anchor="status.306" title="306 (Unused)">
<iref primary="true" item="306 (Unused) (status code)"/> <iref primary="true" item="306 (Unused) (status code)"/>
<t> <t>
The 306 status code was defined in a previous version of this The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
</t> </t>
</section> </section>
<section anchor="status.307" title="307 Temporary Redirect"> <section anchor="status.307" title="307 Temporary Redirect">
<iref primary="true" item="307 Temporary Redirect (status code)"/ > <iref primary="true" item="307 Temporary Redirect (status code)"/ >
<t> <t>
The <em>307 (Temporary Redirect)</em> status code indicates that the The "307 (Temporary Redirect)" status code indicates that the
<xref target="target.resource" format="none">target resource</xref> resides t emporarily under a different URI <xref target="target.resource" format="none">target resource</xref> resides t emporarily under a different URI
and the user agent <bcp14>MUST NOT</bcp14> change the request method if it pe rforms an and the user agent <bcp14>MUST NOT</bcp14> change the request method if it pe rforms an
automatic redirection to that URI. automatic redirection to that URI.
Since the redirection can change over time, the client ought to continue Since the redirection can change over time, the client ought to continue
using the original target URI for future requests. using the original target URI for future requests.
</t> </t>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the The server <bcp14>SHOULD</bcp14> generate a <xref target="field.location" for mat="none">Location</xref> header field in the
response containing a URI reference for the different URI. response containing a URI reference for the different 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 different URI(s). a hyperlink to the different URI(s).
</t> </t>
</section> </section>
<section anchor="status.308" title="308 Permanent Redirect"> <section anchor="status.308" title="308 Permanent Redirect">
<iref primary="true" item="308 Permanent Redirect (status code)"/ > <iref primary="true" item="308 Permanent Redirect (status code)"/ >
<t> <t>
The <em>308 (Permanent Redirect)</em> status code indicates that the The "308 (Permanent Redirect)" status code indicates that the
<xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and <xref target="target.resource" format="none">target resource</xref> has been assigned a new permanent URI and
any future references to this resource ought to use one of the enclosed any future references to this resource ought to use one of the enclosed
URIs. The server is suggesting that a user agent with link-editing capability URIs. The server is suggesting that a user agent with link-editing capability
can permanently replace references to the target URI with one of the can permanently replace references to the target URI with one of the
new references sent by the server. However, this suggestion is usually new references sent by the server. However, this suggestion is usually
ignored unless the user agent is actively editing references ignored unless the user agent is actively editing references
(e.g., engaged in authoring content), the connection is secured, and (e.g., engaged in authoring content), the connection is secured, and
the origin server is a trusted authority for the content being edited. the origin server is a trusted authority for the content being edited.
</t> </t>
<t> <t>
skipping to change at line 9282 skipping to change at line 9277
</t> </t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="status.4xx" title="Client Error 4xx"> <section anchor="status.4xx" title="Client Error 4xx">
<iref primary="true" item="4xx Client Error (status code class)"/> <iref primary="true" item="4xx Client Error (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="4xx Client Error"/> subitem="4xx Client Error"/>
<t> <t>
The <em>4xx (Client Error)</em> class of status code indicates that The "4xx (Client Error)" class of status code indicates that
the client seems to have erred. Except when responding to a HEAD request, the client seems to have erred. Except when responding to a HEAD request,
the server <bcp14>SHOULD</bcp14> send a representation containing an explanat ion of the server <bcp14>SHOULD</bcp14> send a representation containing an explanat ion of
the error situation, and whether it is a temporary or permanent condition. the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents These status codes are applicable to any request method. User agents
<bcp14>SHOULD</bcp14> display any included representation to the user. <bcp14>SHOULD</bcp14> display any included representation to the user.
</t> </t>
<section anchor="status.400" title="400 Bad Request"> <section anchor="status.400" title="400 Bad Request">
<iref primary="true" item="400 Bad Request (status code)"/> <iref primary="true" item="400 Bad Request (status code)"/>
<t> <t>
The <em>400 (Bad Request)</em> status code indicates that the server The "400 (Bad Request)" status code indicates that the server
cannot or will not process the request due to something that is perceived cannot or will not process the request due to something that is perceived
to be a client error (e.g., malformed request syntax, invalid request to be a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing). message framing, or deceptive request routing).
</t> </t>
</section> </section>
<section anchor="status.401" title="401 Unauthorized"> <section anchor="status.401" title="401 Unauthorized">
<iref primary="true" item="401 Unauthorized (status code)"/> <iref primary="true" item="401 Unauthorized (status code)"/>
<t> <t>
The <em>401 (Unauthorized)</em> status code indicates that the The "401 (Unauthorized)" status code indicates that the
request has not been applied because it lacks valid authentication request has not been applied because it lacks valid authentication
credentials for the target resource. credentials for the target resource.
The server generating a 401 response <bcp14>MUST</bcp14> send a The server generating a 401 response <bcp14>MUST</bcp14> send a
<xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field <xref target="field.www-authenticate" format="none">WWW-Authenticate</xref> h eader field
(<xref target="field.www-authenticate"/>) (<xref target="field.www-authenticate"/>)
containing at least one challenge applicable to the target resource. containing at least one challenge applicable to the target resource.
</t> </t>
<t> <t>
If the request included authentication credentials, then the 401 response If the request included authentication credentials, then the 401 response
indicates that authorization has been refused for those credentials. indicates that authorization has been refused for those credentials.
skipping to change at line 9323 skipping to change at line 9318
<xref target="field.authorization" format="none">Authorization</xref> header field (<xref target="field.authorization"/>). <xref target="field.authorization" format="none">Authorization</xref> header field (<xref target="field.authorization"/>).
If the 401 response contains the same challenge as the prior response, and If the 401 response contains the same challenge as the prior response, and
the user agent has already attempted authentication at least once, then the the user agent has already attempted authentication at least once, then the
user agent <bcp14>SHOULD</bcp14> present the enclosed representation to the u ser, since user agent <bcp14>SHOULD</bcp14> present the enclosed representation to the u ser, since
it usually contains relevant diagnostic information. it usually contains relevant diagnostic information.
</t> </t>
</section> </section>
<section anchor="status.402" title="402 Payment Required"> <section anchor="status.402" title="402 Payment Required">
<iref primary="true" item="402 Payment Required (status code)"/> <iref primary="true" item="402 Payment Required (status code)"/>
<t> <t>
The <em>402 (Payment Required)</em> status code is reserved for The "402 (Payment Required)" status code is reserved for
future use. future use.
</t> </t>
</section> </section>
<section anchor="status.403" title="403 Forbidden"> <section anchor="status.403" title="403 Forbidden">
<iref primary="true" item="403 Forbidden (status code)"/> <iref primary="true" item="403 Forbidden (status code)"/>
<t> <t>
The <em>403 (Forbidden)</em> status code indicates that the The "403 (Forbidden)" status code indicates that the
server understood the request but refuses to fulfill it. server understood the request but refuses to fulfill it.
A server that wishes to make public why the request has been forbidden A server that wishes to make public why the request has been forbidden
can describe that reason in the response content (if any). can describe that reason in the response content (if any).
</t> </t>
<t> <t>
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. server considers them insufficient to grant access.
The client <bcp14>SHOULD NOT</bcp14> automatically repeat the request with th e same The client <bcp14>SHOULD NOT</bcp14> automatically repeat the request with th e same
credentials. credentials.
The client <bcp14>MAY</bcp14> repeat the request with new or different creden tials. The client <bcp14>MAY</bcp14> repeat the request with new or different creden tials.
skipping to change at line 9354 skipping to change at line 9349
<t> <t>
An origin server that wishes to "hide" the current existence of a forbidden An origin server that wishes to "hide" the current existence of a forbidden
<xref target="target.resource" format="none">target resource</xref> <xref target="target.resource" format="none">target resource</xref>
<bcp14>MAY</bcp14> instead respond with a status <bcp14>MAY</bcp14> instead respond with a status
code of <xref target="status.404" format="none">404 (Not Found)</xref>. code of <xref target="status.404" format="none">404 (Not Found)</xref>.
</t> </t>
</section> </section>
<section anchor="status.404" title="404 Not Found"> <section anchor="status.404" title="404 Not Found">
<iref primary="true" item="404 Not Found (status code)"/> <iref primary="true" item="404 Not Found (status code)"/>
<t> <t>
The <em>404 (Not Found)</em> status code indicates that the origin The "404 (Not Found)" status code indicates that the origin
server did not find a current representation for the server did not find a current representation for the
<xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one <xref target="target.resource" format="none">target resource</xref> or is not willing to disclose that one
exists. A 404 status code does not indicate whether this lack of representati on exists. A 404 status code does not indicate whether this lack of representati on
is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is is temporary or permanent; the <xref target="status.410" format="none">410 (G one)</xref> status code is
preferred over 404 if the origin server knows, presumably through some preferred over 404 if the origin server knows, presumably through some
configurable means, that the condition is likely to be permanent. configurable means, that the condition is likely to be permanent.
</t> </t>
<t> <t>
A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y A 404 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.405" title="405 Method Not Allowed"> <section anchor="status.405" title="405 Method Not Allowed">
<iref primary="true" item="405 Method Not Allowed (status code)"/ > <iref primary="true" item="405 Method Not Allowed (status code)"/ >
<t> <t>
The <em>405 (Method Not Allowed)</em> status code indicates that the The "405 (Method Not Allowed)" status code indicates that the
method received in the request-line is known by the origin server but method received in the request-line is known by the origin server but
not supported by the <xref target="target.resource" format="none">target reso urce</xref>. not supported by the <xref target="target.resource" format="none">target reso urce</xref>.
The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in The origin server <bcp14>MUST</bcp14> generate an <xref target="field.allow" format="none">Allow</xref> header field in
a 405 response containing a list of the target resource's currently a 405 response containing a list of the target resource's currently
supported methods. supported methods.
</t> </t>
<t> <t>
A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y A 405 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.406" title="406 Not Acceptable"> <section anchor="status.406" title="406 Not Acceptable">
<iref primary="true" item="406 Not Acceptable (status code)"/> <iref primary="true" item="406 Not Acceptable (status code)"/>
<t> <t>
The <em>406 (Not Acceptable)</em> status code indicates that the The "406 (Not Acceptable)" status code indicates that the
<xref target="target.resource" format="none">target resource</xref> does not have a current representation that <xref target="target.resource" format="none">target resource</xref> does not have a current representation that
would be acceptable to the user agent, according to the would be acceptable to the user agent, according to the
<xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request <xref target="proactive.negotiation" format="none">proactive negotiation</xre f> header fields received in the request
(<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a (<xref target="proactive.negotiation"/>), and the server is unwilling to supp ly a
default representation. default representation.
</t> </t>
<t> <t>
The server <bcp14>SHOULD</bcp14> generate content containing a list of availa ble The server <bcp14>SHOULD</bcp14> generate content containing a list of availa ble
representation characteristics and corresponding resource identifiers from representation characteristics and corresponding resource identifiers from
which the user or user agent can choose the one most appropriate. which the user or user agent can choose the one most appropriate.
A user agent <bcp14>MAY</bcp14> automatically select the most appropriate cho ice from A user agent <bcp14>MAY</bcp14> automatically select the most appropriate cho ice from
that list. However, this specification does not define any standard for that list. However, this specification does not define any standard for
such automatic selection, as described in <xref target="status.300"/>. such automatic selection, as described in <xref target="status.300"/>.
</t> </t>
</section> </section>
<section anchor="status.407" title="407 Proxy Authentication Require d"> <section anchor="status.407" title="407 Proxy Authentication Require d">
<iref primary="true" item="407 Proxy Authentication Required (sta tus code)"/> <iref primary="true" item="407 Proxy Authentication Required (sta tus code)"/>
<t> <t>
The <em>407 (Proxy Authentication Required)</em> status code is The "407 (Proxy Authentication Required)" status code is
similar to <xref target="status.401" format="none">401 (Unauthorized)</xref>, but it indicates that the client similar to <xref target="status.401" format="none">401 (Unauthorized)</xref>, but it indicates that the client
needs to authenticate itself in order to use a proxy for this request. needs to authenticate itself in order to use a proxy for this request.
The proxy <bcp14>MUST</bcp14> send a <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field The proxy <bcp14>MUST</bcp14> send a <xref target="field.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field
(<xref target="field.proxy-authenticate"/>) containing a challenge (<xref target="field.proxy-authenticate"/>) containing a challenge
applicable to that proxy for the request. The client <bcp14>MAY</bcp14> repea t applicable to that proxy for the request. The client <bcp14>MAY</bcp14> repea t
the request with a new or replaced <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref> the request with a new or replaced <xref target="field.proxy-authorization" f ormat="none">Proxy-Authorization</xref>
header field (<xref target="field.proxy-authorization"/>). header field (<xref target="field.proxy-authorization"/>).
</t> </t>
</section> </section>
<section anchor="status.408" title="408 Request Timeout"> <section anchor="status.408" title="408 Request Timeout">
<iref primary="true" item="408 Request Timeout (status code)"/> <iref primary="true" item="408 Request Timeout (status code)"/>
<t> <t>
The <em>408 (Request Timeout)</em> status code indicates The "408 (Request Timeout)" status code indicates
that the server did not receive a complete request message within the time that the server did not receive a complete request message within the time
that it was prepared to wait. that it was prepared to wait.
</t> </t>
<t> <t>
If the client has an outstanding request in transit, it <bcp14>MAY</bcp14> re peat that If the client has an outstanding request in transit, it <bcp14>MAY</bcp14> re peat that
request. If the current connection is not usable (e.g., as it would be in request. If the current connection is not usable (e.g., as it would be in
HTTP/1.1 because request delimitation is lost), a new connection will be HTTP/1.1 because request delimitation is lost), a new connection will be
used. used.
</t> </t>
</section> </section>
<section anchor="status.409" title="409 Conflict"> <section anchor="status.409" title="409 Conflict">
<iref primary="true" item="409 Conflict (status code)"/> <iref primary="true" item="409 Conflict (status code)"/>
<t> <t>
The <em>409 (Conflict)</em> status code indicates that the request The "409 (Conflict)" status code indicates that the request
could not be completed due to a conflict with the current state of the target could not be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be able to resource. This code is used in situations where the user might be able to
resolve the conflict and resubmit the request. The server <bcp14>SHOULD</bcp1 4> generate resolve the conflict and resubmit the request. The server <bcp14>SHOULD</bcp1 4> generate
content that includes enough information for a user to recognize the content that includes enough information for a user to recognize the
source of the conflict. source of the conflict.
</t> </t>
<t> <t>
Conflicts are most likely to occur in response to a PUT request. For Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being PUT example, if versioning were being used and the representation being PUT
included changes to a resource that conflict with those made by an included changes to a resource that conflict with those made by an
earlier (third-party) request, the origin server might use a 409 response earlier (third-party) request, the origin server might use a 409 response
to indicate that it can't complete the request. In this case, the response to indicate that it can't complete the request. In this case, the response
representation would likely contain information useful for merging the representation would likely contain information useful for merging the
differences based on the revision history. differences based on the revision history.
</t> </t>
</section> </section>
<section anchor="status.410" title="410 Gone"> <section anchor="status.410" title="410 Gone">
<iref primary="true" item="410 Gone (status code)"/> <iref primary="true" item="410 Gone (status code)"/>
<t> <t>
The <em>410 (Gone)</em> status code indicates that access to the The "410 (Gone)" status code indicates that access to the
<xref target="target.resource" format="none">target resource</xref> is no lon ger available at the origin <xref target="target.resource" format="none">target resource</xref> is no lon ger available at the origin
server and that this condition is likely to be permanent. If the origin server and that this condition is likely to be permanent. If the origin
server does not know, or has no facility to determine, whether or not the server does not know, or has no facility to determine, whether or not the
condition is permanent, the status code <xref target="status.404" format="non e">404 (Not Found)</xref> condition is permanent, the status code <xref target="status.404" format="non e">404 (Not Found)</xref>
ought to be used instead. ought to be used instead.
</t> </t>
<t> <t>
The 410 response is primarily intended to assist the task of web The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
skipping to change at line 9477 skipping to change at line 9472
discretion of the server owner. discretion of the server owner.
</t> </t>
<t> <t>
A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y A 410 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.411" title="411 Length Required"> <section anchor="status.411" title="411 Length Required">
<iref primary="true" item="411 Length Required (status code)"/> <iref primary="true" item="411 Length Required (status code)"/>
<t> <t>
The <em>411 (Length Required)</em> status code indicates that the The "411 (Length Required)" status code indicates that the
server refuses to accept the request without a defined server refuses to accept the request without a defined
<xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>). <xref target="field.content-length" format="none">Content-Length</xref> (<xre f target="field.content-length"/>).
The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength The client <bcp14>MAY</bcp14> repeat the request if it adds a valid Content-L ength
header field containing the length of the request content. header field containing the length of the request content.
</t> </t>
</section> </section>
<section anchor="status.412" title="412 Precondition Failed"> <section anchor="status.412" title="412 Precondition Failed">
<iref primary="true" item="412 Precondition Failed (status code)" /> <iref primary="true" item="412 Precondition Failed (status code)" />
<t> <t>
The <em>412 (Precondition Failed)</em> status code indicates that one The "412 (Precondition Failed)" status code indicates that one
or more conditions given in the request header fields evaluated to false or more conditions given in the request header fields evaluated to false
when tested on the server (<xref target="conditional.requests"/>). This when tested on the server (<xref target="conditional.requests"/>). This
response status code allows the client to place preconditions on the response status code allows the client to place preconditions on the
current resource state (its current representations and metadata) and, current resource state (its current representations and metadata) and,
thus, prevent the request method from being applied if the target resource thus, prevent the request method from being applied if the target resource
is in an unexpected state. is in an unexpected state.
</t> </t>
</section> </section>
<section anchor="status.413" title="413 Content Too Large"> <section anchor="status.413" title="413 Content Too Large">
<iref primary="true" item="413 Content Too Large (status code)"/> <iref primary="true" item="413 Content Too Large (status code)"/>
<t> <t>
The <em>413 (Content Too Large)</em> status code indicates The "413 (Content Too Large)" status code indicates
that the server is refusing to process a request because the request that the server is refusing to process a request because the request
content is larger than the server is willing or able to process. content is larger than the server is willing or able to process.
The server <bcp14>MAY</bcp14> terminate the request, if the protocol version in use The server <bcp14>MAY</bcp14> terminate the request, if the protocol version in use
allows it; otherwise, the server <bcp14>MAY</bcp14> close the connection. allows it; otherwise, the server <bcp14>MAY</bcp14> close the connection.
</t> </t>
<t> <t>
If the condition is temporary, the server <bcp14>SHOULD</bcp14> generate a If the condition is temporary, the server <bcp14>SHOULD</bcp14> generate a
<xref target="field.retry-after" format="none">Retry-After</xref> header fiel d to indicate that it is temporary <xref target="field.retry-after" format="none">Retry-After</xref> header fiel d to indicate that it is temporary
and after what time the client <bcp14>MAY</bcp14> try again. and after what time the client <bcp14>MAY</bcp14> try again.
</t> </t>
</section> </section>
<section anchor="status.414" title="414 URI Too Long"> <section anchor="status.414" title="414 URI Too Long">
<iref primary="true" item="414 URI Too Long (status code)"/> <iref primary="true" item="414 URI Too Long (status code)"/>
<t> <t>
The <em>414 (URI Too Long)</em> status code indicates that the server The "414 (URI Too Long)" status code indicates that the server
is refusing to service the request because the is refusing to service the request because the
target URI is longer than the server is willing to target URI is longer than the server is willing to
interpret. This rare condition is only likely to occur when a client has interpret. This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to itself) or when the server is under attack by a client attempting to
exploit potential security holes. exploit potential security holes.
</t> </t>
<t> <t>
A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y A 414 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.415" title="415 Unsupported Media Type"> <section anchor="status.415" title="415 Unsupported Media Type">
<iref primary="true" item="415 Unsupported Media Type (status cod e)"/> <iref primary="true" item="415 Unsupported Media Type (status cod e)"/>
<t> <t>
The <em>415 (Unsupported Media Type)</em> status code indicates that The "415 (Unsupported Media Type)" status code indicates that
the origin server is refusing to service the request because the content is the origin server is refusing to service the request because the content is
in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>. in a format not supported by this method on the <xref target="target.resource " format="none">target resource</xref>.
</t> </t>
<t> <t>
The format problem might be due to the request's indicated The format problem might be due to the request's indicated
<xref target="field.content-type" format="none">Content-Type</xref> or <xref target="field.content-encoding" format="none">Content-Encoding</xref>, or as a <xref target="field.content-type" format="none">Content-Type</xref> or <xref target="field.content-encoding" format="none">Content-Encoding</xref>, or as a
result of inspecting the data directly. result of inspecting the data directly.
</t> </t>
<t> <t>
If the problem was caused by an unsupported content coding, the If the problem was caused by an unsupported content coding, the
skipping to change at line 9558 skipping to change at line 9553
<t> <t>
On the other hand, if the cause was an unsupported media type, the On the other hand, if the cause was an unsupported media type, the
<xref target="field.accept" format="none">Accept</xref> response header field (<xref target="field.accept"/>) <xref target="field.accept" format="none">Accept</xref> response header field (<xref target="field.accept"/>)
can be used to indicate which media types would have been accepted can be used to indicate which media types would have been accepted
in the request. in the request.
</t> </t>
</section> </section>
<section anchor="status.416" title="416 Range Not Satisfiable"> <section anchor="status.416" title="416 Range Not Satisfiable">
<iref primary="true" item="416 Range Not Satisfiable (status code )"/> <iref primary="true" item="416 Range Not Satisfiable (status code )"/>
<t> <t>
The <em>416 (Range Not Satisfiable)</em> status code indicates that The "416 (Range Not Satisfiable)" status code indicates that
the set of ranges in the request's <xref target="field.range" format="none">R ange</xref> header field the set of ranges in the request's <xref target="field.range" format="none">R ange</xref> header field
(<xref target="field.range"/>) has been rejected either because none of (<xref target="field.range"/>) has been rejected either because none of
the requested ranges are satisfiable or because the client has requested the requested ranges are satisfiable or because the client has requested
an excessive number of small or overlapping ranges (a potential denial of an excessive number of small or overlapping ranges (a potential denial of
service attack). service attack).
</t> </t>
<t> <t>
Each range unit defines what is required for its own range sets to be Each range unit defines what is required for its own range sets to be
satisfiable. For example, <xref target="byte.ranges"/> defines what makes satisfiable. For example, <xref target="byte.ranges"/> defines what makes
a bytes range set satisfiable. a bytes range set satisfiable.
skipping to change at line 9600 skipping to change at line 9595
might not stop making an invalid range request until they have received might not stop making an invalid range request until they have received
a complete representation. Thus, clients cannot depend on receiving a a complete representation. Thus, clients cannot depend on receiving a
<xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> r esponse even when it is most <xref target="status.416" format="none">416 (Range Not Satisfiable)</xref> r esponse even when it is most
appropriate. appropriate.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.417" title="417 Expectation Failed"> <section anchor="status.417" title="417 Expectation Failed">
<iref primary="true" item="417 Expectation Failed (status code)"/ > <iref primary="true" item="417 Expectation Failed (status code)"/ >
<t> <t>
The <em>417 (Expectation Failed)</em> status code indicates that the The "417 (Expectation Failed)" status code indicates that the
expectation given in the request's <xref target="field.expect" format="none"> Expect</xref> header field expectation given in the request's <xref target="field.expect" format="none"> Expect</xref> header field
(<xref target="field.expect"/>) could not be met by at least one of the (<xref target="field.expect"/>) could not be met by at least one of the
inbound servers. inbound servers.
</t> </t>
</section> </section>
<section anchor="status.418" title="418 (Unused)"> <section anchor="status.418" title="418 (Unused)">
<iref primary="true" item="418 (Unused) (status code)"/> <iref primary="true" item="418 (Unused) (status code)"/>
<t> <t>
<xref target="RFC2324"/> is an April 1st RFC that lampoons the various <xref target="RFC2324"/> is an April 1st RFC that lampoons the various
skipping to change at line 9638 skipping to change at line 9633
<t> <t>
Therefore, the 418 status code is reserved in the IANA "Hypertext Transfer Pr otocol (HTTP) Status Code Therefore, the 418 status code is reserved in the IANA "Hypertext Transfer Pr otocol (HTTP) Status Code
Registry". This indicates that the status code cannot be assigned to other Registry". This indicates that the status code cannot be assigned to other
applications currently. If future circumstances require its use (e.g., applications currently. If future circumstances require its use (e.g.,
exhaustion of 4NN status codes), it can be re-assigned to another use. exhaustion of 4NN status codes), it can be re-assigned to another use.
</t> </t>
</section> </section>
<section anchor="status.421" title="421 Misdirected Request"> <section anchor="status.421" title="421 Misdirected Request">
<iref primary="true" item="421 Misdirected Request (status code)" /> <iref primary="true" item="421 Misdirected Request (status code)" />
<t> <t>
The <em>421 (Misdirected Request)</em> status code indicates that the request was The "421 (Misdirected Request)" status code indicates that the request was
directed at a server that is unable or unwilling to produce an directed at a server that is unable or unwilling to produce an
authoritative response for the target URI. An origin server (or gateway authoritative response for the target URI. An origin server (or gateway
acting on behalf of the origin server) sends 421 to reject a target URI acting on behalf of the origin server) sends 421 to reject a target URI
that does not match an <xref target="origin" format="none">origin</xref> for which the server has been that does not match an <xref target="origin" format="none">origin</xref> for which the server has been
configured (<xref target="origin"/>) or does not match the connection configured (<xref target="origin"/>) or does not match the connection
context over which the request was received context over which the request was received
(<xref target="routing.reject"/>). (<xref target="routing.reject"/>).
</t> </t>
<t> <t>
A client that receives a 421 (Misdirected Request) response <bcp14>MAY</bcp14 > retry the A client that receives a 421 (Misdirected Request) response <bcp14>MAY</bcp14 > retry the
skipping to change at line 9660 skipping to change at line 9655
connection, such as a fresh connection specific to the target resource's connection, such as a fresh connection specific to the target resource's
origin, or via an alternative service <xref target="ALTSVC"/>. origin, or via an alternative service <xref target="ALTSVC"/>.
</t> </t>
<t> <t>
A proxy <bcp14>MUST NOT</bcp14> generate a 421 response. A proxy <bcp14>MUST NOT</bcp14> generate a 421 response.
</t> </t>
</section> </section>
<section anchor="status.422" title="422 Unprocessable Content"> <section anchor="status.422" title="422 Unprocessable Content">
<iref primary="true" item="422 Unprocessable Content (status code )"/> <iref primary="true" item="422 Unprocessable Content (status code )"/>
<t> <t>
The <em>422 (Unprocessable Content)</em> status code indicates that the serve r The "422 (Unprocessable Content)" 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
<xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code is inappropriate), <xref target="status.415" format="none">415 (Unsupported Media Type)</xref> s tatus code is inappropriate),
and the syntax of the request content is correct, but it was unable to proces s and the syntax of the request content is correct, but it was unable to proces s
the contained instructions. For example, this status code can be sent if the contained instructions. For example, this status code can be sent if
an XML request content contains well-formed (i.e., syntactically correct), bu t an XML request content contains well-formed (i.e., syntactically correct), bu t
semantically erroneous XML instructions. semantically erroneous XML instructions.
</t> </t>
</section> </section>
<section anchor="status.426" title="426 Upgrade Required"> <section anchor="status.426" title="426 Upgrade Required">
<iref primary="true" item="426 Upgrade Required (status code)"/> <iref primary="true" item="426 Upgrade Required (status code)"/>
<t> <t>
The <em>426 (Upgrade Required)</em> status code indicates that the The "426 (Upgrade Required)" status code indicates that the
server refuses to perform the request using the current protocol but might server refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different protocol. be willing to do so after the client upgrades to a different protocol.
The server <bcp14>MUST</bcp14> send an <xref target="field.upgrade" format="n one">Upgrade</xref> header field in a 426 The server <bcp14>MUST</bcp14> send an <xref target="field.upgrade" format="n one">Upgrade</xref> header field in a 426
response to indicate the required protocol(s) (<xref target="field.upgrade"/> ). response to indicate the required protocol(s) (<xref target="field.upgrade"/> ).
</t> </t>
<t> <t>
Example: Example:
</t> </t>
<sourcecode type="http-message"><![CDATA[HTTP/1.1 426 Upgrade Req uired <sourcecode type="http-message"><![CDATA[HTTP/1.1 426 Upgrade Req uired
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
skipping to change at line 9697 skipping to change at line 9692
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="status.5xx" title="Server Error 5xx"> <section anchor="status.5xx" title="Server Error 5xx">
<iref primary="true" item="5xx Server Error (status code class)"/> <iref primary="true" item="5xx Server Error (status code class)"/>
<iref primary="true" <iref primary="true"
item="Status Codes Classes" item="Status Codes Classes"
subitem="5xx Server Error"/> subitem="5xx Server Error"/>
<t> <t>
The <em>5xx (Server Error)</em> class of status code indicates that The "5xx (Server Error)" class of status code indicates that
the server is aware that it has erred or is incapable of performing the the server is aware that it has erred or is incapable of performing the
requested method. requested method.
Except when responding to a HEAD request, the server <bcp14>SHOULD</bcp14> se nd a Except when responding to a HEAD request, the server <bcp14>SHOULD</bcp14> se nd a
representation containing an explanation of the error situation, and representation containing an explanation of the error situation, and
whether it is a temporary or permanent condition. whether it is a temporary or permanent condition.
A user agent <bcp14>SHOULD</bcp14> display any included representation to the user. A user agent <bcp14>SHOULD</bcp14> display any included representation to the user.
These status codes are applicable to any request method. These status codes are applicable to any request method.
</t> </t>
<section anchor="status.500" title="500 Internal Server Error"> <section anchor="status.500" title="500 Internal Server Error">
<iref primary="true" item="500 Internal Server Error (status code )"/> <iref primary="true" item="500 Internal Server Error (status code )"/>
<t> <t>
The <em>500 (Internal Server Error)</em> status code indicates that The "500 (Internal Server Error)" status code indicates that
the server encountered an unexpected condition that prevented it from the server encountered an unexpected condition that prevented it from
fulfilling the request. fulfilling the request.
</t> </t>
</section> </section>
<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 "501 (Not Implemented)" status code indicates that the
server does not support the functionality required to fulfill the request. server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the This is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. request method and is not capable of supporting it for any resource.
</t> </t>
<t> <t>
A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y A 501 response is heuristically cacheable; i.e., unless otherwise indicated b y
the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>). the method definition or explicit cache controls (see <xref target="CACHING" section="4.2.2"/>).
</t> </t>
</section> </section>
<section anchor="status.502" title="502 Bad Gateway"> <section anchor="status.502" title="502 Bad Gateway">
<iref primary="true" item="502 Bad Gateway (status code)"/> <iref primary="true" item="502 Bad Gateway (status code)"/>
<t> <t>
The <em>502 (Bad Gateway)</em> status code indicates that the server, The "502 (Bad Gateway)" 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>
<section anchor="status.503" title="503 Service Unavailable"> <section anchor="status.503" title="503 Service Unavailable">
<iref primary="true" item="503 Service Unavailable (status code)" /> <iref primary="true" item="503 Service Unavailable (status code)" />
<t> <t>
The <em>503 (Service Unavailable)</em> status code indicates that the The "503 (Service Unavailable)" status code indicates that the
server is currently unable to handle the request due to a temporary overload server is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some delay. or scheduled maintenance, which will likely be alleviated after some delay.
The server <bcp14>MAY</bcp14> send a <xref target="field.retry-after" format= "none">Retry-After</xref> header field The server <bcp14>MAY</bcp14> send a <xref target="field.retry-after" format= "none">Retry-After</xref> header field
(<xref target="field.retry-after"/>) to suggest an appropriate (<xref target="field.retry-after"/>) to suggest an appropriate
amount of time for the client to wait before retrying the request. amount of time for the client to wait before retrying the request.
</t> </t>
<aside> <aside>
<t> <t>
<strong>Note:</strong> The existence of the 503 status code does not imply that a <strong>Note:</strong> The existence of the 503 status code does not imply that a
server has to use it when becoming overloaded. Some servers might server has to use it when becoming overloaded. Some servers might
simply refuse the connection. simply refuse the connection.
</t> </t>
</aside> </aside>
</section> </section>
<section anchor="status.504" title="504 Gateway Timeout"> <section anchor="status.504" title="504 Gateway Timeout">
<iref primary="true" item="504 Gateway Timeout (status code)"/> <iref primary="true" item="504 Gateway Timeout (status code)"/>
<t> <t>
The <em>504 (Gateway Timeout)</em> status code indicates that the The "504 (Gateway Timeout)" status code indicates that the
server, while acting as a gateway or proxy, did not receive a timely server, while acting as a gateway or proxy, did not receive a timely
response from an upstream server it needed to access in order to response from an upstream server it needed to access in order to
complete the request. complete the request.
</t> </t>
</section> </section>
<section anchor="status.505" title="505 HTTP Version Not Supported"> <section anchor="status.505" title="505 HTTP Version Not Supported">
<iref primary="true" item="505 HTTP Version Not Supported (status code)"/> <iref primary="true" item="505 HTTP Version Not Supported (status code)"/>
<t> <t>
The <em>505 (HTTP Version Not Supported)</em> status code indicates The "505 (HTTP Version Not Supported)" status code indicates
that the server does not support, or refuses to support, the major version that the server does not support, or refuses to support, the major version
of HTTP that was used in the request message. The server is indicating that of HTTP that was used in the request message. The server is indicating that
it is unable or unwilling to complete the request using the same major it is unable or unwilling to complete the request using the same major
version as the client, as described in <xref target="protocol.version"/>, oth er than with this version as the client, as described in <xref target="protocol.version"/>, oth er than with this
error message. The server <bcp14>SHOULD</bcp14> generate a representation for the 505 error message. The server <bcp14>SHOULD</bcp14> generate a representation for the 505
response that describes why that version is not supported and what other response that describes why that version is not supported and what other
protocols are supported by that server. protocols are supported by that server.
</t> </t>
</section> </section>
</section> </section>
skipping to change at line 10473 skipping to change at line 10468
security of the protocol. The security considerations for URIs, which security of the protocol. The security considerations for URIs, which
are fundamental to HTTP operation, are discussed in are fundamental to HTTP operation, are discussed in
<xref target="URI" section="7"/>. Various organizations maintain <xref target="URI" section="7"/>. Various organizations maintain
topical information and links to current research on Web application topical information and links to current research on Web application
security (e.g., <xref target="OWASP"/>). security (e.g., <xref target="OWASP"/>).
</t> </t>
<section anchor="establishing.authority" title="Establishing Authority" > <section anchor="establishing.authority" title="Establishing Authority" >
<iref item="authoritative response" primary="true"/> <iref item="authoritative response" primary="true"/>
<iref item="phishing" primary="true"/> <iref item="phishing" primary="true"/>
<t> <t>
HTTP relies on the notion of an <em>authoritative response</em>: a HTTP relies on the notion of an "authoritative response": 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
for that request given the state of the target resource at the time of for that request given the state of the target resource at the time of
response message origination. response message origination.
</t> </t>
<t> <t>
When a registered name is used in the authority component, the "http" URI When a registered name is used in the authority component, the "http" URI
scheme (<xref target="http.uri"/>) relies on the user's local name scheme (<xref target="http.uri"/>) relies on the user's local name
resolution service to determine where it can find authoritative responses. resolution service to determine where it can find authoritative responses.
This means that any attack on a user's network host table, cached names, This means that any attack on a user's network host table, cached names,
skipping to change at line 10519 skipping to change at line 10514
with a protocol extension like <xref target="RFC8336"/>. with a protocol extension like <xref target="RFC8336"/>.
</t> </t>
<t> <t>
Providing a response from a non-authoritative source, such as a shared Providing a response from a non-authoritative source, such as a shared
proxy cache, is often useful to improve performance and availability, but proxy cache, is often useful to improve performance and availability, but
only to the extent that the source can be trusted or the distrusted only to the extent that the source can be trusted or the distrusted
response can be safely used. response can be safely used.
</t> </t>
<t> <t>
Unfortunately, communicating authority to users can be difficult. Unfortunately, communicating authority to users can be difficult.
For example, <em>phishing</em> is an attack on the user's perception For example, "phishing" is an attack on the user's perception
of authority, where that perception can be misled by presenting similar of authority, where that perception can be misled by presenting similar
branding in hypertext, possibly aided by userinfo obfuscating the authority branding in hypertext, possibly aided by userinfo obfuscating the authority
component (see <xref target="http.uri"/>). component (see <xref target="http.uri"/>).
User agents can reduce the impact of phishing attacks by enabling users to User agents can reduce the impact of phishing attacks by enabling users to
easily inspect a target URI prior to making an action, by prominently easily inspect a target URI prior to making an action, by prominently
distinguishing (or rejecting) userinfo when present, and by not sending distinguishing (or rejecting) userinfo when present, and by not sending
stored credentials and cookies when the referring document is from an stored credentials and cookies when the referring document is from an
unknown or untrusted source. unknown or untrusted source.
</t> </t>
</section> </section>
skipping to change at line 12912 skipping to change at line 12907
The use of the <xref target="field.content-range" format="none">Content-Range </xref> header field The use of the <xref target="field.content-range" format="none">Content-Range </xref> header field
(<xref target="field.content-range"/>) as a request modifier on PUT is allowe d. (<xref target="field.content-range"/>) as a request modifier on PUT is allowe d.
(<xref target="PUT"/>) (<xref target="PUT"/>)
</t> </t>
<t> <t>
A superfluous requirement about setting <xref target="field.content-length" f ormat="none">Content-Length</xref> A superfluous requirement about setting <xref target="field.content-length" f ormat="none">Content-Length</xref>
has been removed from the description of the OPTIONS method. has been removed from the description of the OPTIONS method.
(<xref target="OPTIONS"/>) (<xref target="OPTIONS"/>)
</t> </t>
<t> <t>
The normative requirement to use the message/http media type in The normative requirement to use the "message/http" media type in
TRACE responses has been removed. TRACE responses has been removed.
(<xref target="TRACE"/>) (<xref target="TRACE"/>)
</t> </t>
<t> <t>
List-based grammar for <xref target="field.expect" format="none">Expect</xref > has been restored for compatibility with List-based grammar for <xref target="field.expect" format="none">Expect</xref > has been restored for compatibility with
RFC 2616. RFC 2616.
(<xref target="field.expect"/>) (<xref target="field.expect"/>)
</t> </t>
<t> <t>
<xref target="field.accept" format="none">Accept</xref> and <xref target="fie ld.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response <xref target="field.accept" format="none">Accept</xref> and <xref target="fie ld.accept-encoding" format="none">Accept-Encoding</xref> are allowed in response
 End of changes. 121 change blocks. 
134 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/