draft-ietf-httpbis-semantics-latest.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='lib/myxml2rfc.xslt'?>
<!DOCTYPE rfc [
  <!ENTITY MAY "<bcp14>MAY</bcp14>">
  <!ENTITY MUST "<bcp14>MUST</bcp14>">
  <!ENTITY MUST-NOT "<bcp14>MUST NOT</bcp14>">
  <!ENTITY OPTIONAL "<bcp14>OPTIONAL</bcp14>">
  <!ENTITY RECOMMENDED "<bcp14>RECOMMENDED</bcp14>">
  <!ENTITY REQUIRED "<bcp14>REQUIRED</bcp14>">
  <!ENTITY SHALL "<bcp14>SHALL</bcp14>">
  <!ENTITY SHALL-NOT "<bcp14>SHALL NOT</bcp14>">
  <!ENTITY SHOULD "<bcp14>SHOULD</bcp14>">
  <!ENTITY SHOULD-NOT "<bcp14>SHOULD NOT</bcp14>">
  <!ENTITY ID-VERSION "latest">
  <!ENTITY ID-MONTH "May">
  <!ENTITY ID-YEAR "2018">
  <!ENTITY mdash "&#8212;">
  <!ENTITY nbhy  "&#x2011;">
  <!ENTITY nbsp "&#160;">
  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext html-pretty-print="prettyprint https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"?>
<?rfc-ext include-references-in-index="yes" ?>

<rfc obsoletes="7230,7231,7232,7233,7235"
     category="std" x:maturity-level="proposed"
     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-semantics-&ID-VERSION;"
     xmlns:x='http://purl.org/net/xml2rfc/ext'
     xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
<front>

  <title>HTTP Semantics</title>

  <author fullname="Roy T. Fielding" initials="R." surname="Fielding" role="editor">
    <organization>Adobe</organization>
    <address>
      <postal>
        <street>345 Park Ave</street>
        <city>San Jose</city>
        <region>CA</region>
        <code>95110</code>
        <country>USA</country>
      </postal>
      <email>fielding@gbiv.com</email>
      <uri>https://roy.gbiv.com/</uri>
    </address>
  </author>

  <author fullname="Mark Nottingham" initials="M." surname="Nottingham" role="editor">
    <organization>Fastly</organization>
    <address>
      <email>mnot@mnot.net</email>
      <uri>https://www.mnot.net/</uri>
    </address>
  </author>

  <author fullname="Julian F. Reschke" initials="J. F." surname="Reschke" role="editor">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>
      <uri>https://greenbytes.de/tech/webdav/</uri>
    </address>
  </author>

  <date month="&ID-MONTH;" year="&ID-YEAR;"/>

  <area>Applications and Real-Time</area>
  <workgroup>HTTP</workgroup>

  <keyword>Hypertext Transfer Protocol</keyword>
  <keyword>HTTP</keyword>
  <keyword>HTTP semantics</keyword>
  <keyword>HTTP payload</keyword>
  <keyword>HTTP content</keyword>
  <keyword>HTTP method</keyword>
  <keyword>HTTP status code</keyword>

<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
   protocol for distributed, collaborative, hypertext information systems.
   This document defines the semantics of HTTP: its architecture,
   terminology, the "http" and "https" Uniform Resource Identifier (URI)
   schemes, core request methods, request header fields, response status
   codes, response header fields, and content negotiation.
</t>
<t>
   This document obsoletes RFC 7231, RFC 7232, RFC 7233,
   RFC 7235, and portions of RFC 7230.
</t>
</abstract>

<note title="Editorial Note" removeInRFC="true">
  <t>
    Discussion of this draft takes place on the HTTP working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
  </t>
  <t>
    Working Group information can be found at <eref target="https://httpwg.org/"/>;
    source code and issues list for this draft can be found at
    <eref target="https://github.com/httpwg/http-core"/>.
  </t>
  <t>
    The changes in this draft are summarized in <xref target="changes.since.01"/>.
  </t>
</note>
</front>

<middle>
<section title="Introduction" anchor="introduction">
<t>
   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
   request/response protocol that uses extensible semantics and
   self-descriptive messages for flexible interaction with network-based
   hypertext information systems. HTTP is defined by a series of documents
   that collectively form the HTTP/1.1 specification:
</t>
<ul>
  <li>"HTTP Semantics" (this document)</li>
  <li>"HTTP Caching" <xref target="Caching"/></li>
  <li>"HTTP/1.1 Messaging" <xref target="Messaging"/></li>
</ul>
<t>
   HTTP is a generic interface protocol for information systems. It is
   designed to hide the details of how a service is implemented by presenting
   a uniform interface to clients that is independent of the types of
   resources provided. Likewise, servers do not need to be aware of each
   client's purpose: an HTTP request can be considered in isolation rather
   than being associated with a specific type of client or a predetermined
   sequence of application steps. The result is a protocol that can be used
   effectively in many different contexts and for which implementations can
   evolve independently over time.
</t>
<t>
   HTTP is also designed for use as an intermediation protocol for translating
   communication to and from non-HTTP information systems.
   HTTP proxies and gateways can provide access to alternative information
   services by translating their diverse protocols into a hypertext
   format that can be viewed and manipulated by clients in the same way
   as HTTP services.
</t>
<t>
   One consequence of this flexibility is that the protocol cannot be
   defined in terms of what occurs behind the interface. Instead, we
   are limited to defining the syntax of communication, the intent
   of received communication, and the expected behavior of recipients.
   If the communication is considered in isolation, then successful
   actions ought to be reflected in corresponding changes to the
   observable interface provided by servers. However, since multiple
   clients might act in parallel and perhaps at cross-purposes, we
   cannot require that such changes be observable beyond the scope
   of a single response.
</t>
<t>
   Each HTTP message is either a request or a
   response. A server listens on a connection for a request, parses each
   message received, interprets the message semantics in relation to the
   identified request target, and responds to that request with one or more
   response messages. A client constructs request messages to communicate
   specific intentions, examines received responses to see if the
   intentions were carried out, and determines how to interpret the results.
</t>
<t>
   HTTP provides a uniform interface for interacting with a resource
   (<xref target="resources"/>), regardless of its type, nature, or
   implementation, via the manipulation and transfer of representations
   (<xref target="representations"/>).
</t>
<t>
   This document defines semantics that are common to all versions of HTTP.
   HTTP semantics include the intentions defined by each request method
   (<xref target="methods"/>), extensions to those semantics that might be
   described in request header fields (<xref target="request.header.fields"/>),
   the meaning of status codes to indicate a machine-readable response
   (<xref target="status.codes"/>), and the meaning of other control data
   and resource metadata that might be given in response header fields
   (<xref target="response.header.fields"/>).
</t>
<t><iref item="content negotiation"/>
   This document also defines representation metadata that describe how a
   payload is intended to be interpreted by a recipient, the request header
   fields that might influence content selection, and the various selection
   algorithms that are collectively referred to as
   "<x:dfn>content negotiation</x:dfn>" (<xref target="content.negotiation"/>).
</t>
<t>
   This document defines HTTP/1.1 range requests, partial responses, and the
   multipart/byteranges media type.
</t>
<t>
   This document obsoletes the portions of
   <xref target="RFC7230" x:fmt="none">RFC 7230</xref> that are independent of
   the HTTP/1.1 messaging syntax and connection management, with the changes
   being summarized in <xref target="changes.from.rfc.7230"/>.
   The other parts of <xref target="RFC7230" x:fmt="none">RFC 7230</xref> are
   obsoleted by "HTTP/1.1 Messaging" <xref target="Messaging"/>.
   This document also obsoletes
   <xref target="RFC7231" x:fmt="none">RFC 7231</xref>
   (see <xref target="changes.from.rfc.7231"/>),
   <xref target="RFC7232" x:fmt="none">RFC 7232</xref>
   (see <xref target="changes.from.rfc.7232"/>),
   <xref target="RFC7233" x:fmt="none">RFC 7233</xref>
   (see <xref target="changes.from.rfc.7233"/>), and
   <xref target="RFC7235" x:fmt="none">RFC 7235</xref>
   (see <xref target="changes.from.rfc.7235"/>).
</t>

<section title="Requirements Notation" anchor="intro.requirements">
<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
   Conformance criteria and considerations regarding error handling
   are defined in <xref target="conformance"/>.
</t>
</section>

<section title="Syntax Notation" anchor="notation">
<iref primary="true" item="Grammar" subitem="ALPHA"/>
<iref primary="true" item="Grammar" subitem="CR"/>
<iref primary="true" item="Grammar" subitem="CRLF"/>
<iref primary="true" item="Grammar" subitem="CTL"/>
<iref primary="true" item="Grammar" subitem="DIGIT"/>
<iref primary="true" item="Grammar" subitem="DQUOTE"/>
<iref primary="true" item="Grammar" subitem="HEXDIG"/>
<iref primary="true" item="Grammar" subitem="HTAB"/>
<iref primary="true" item="Grammar" subitem="LF"/>
<iref primary="true" item="Grammar" subitem="OCTET"/>
<iref primary="true" item="Grammar" subitem="SP"/>
<iref primary="true" item="Grammar" subitem="VCHAR"/>
<t>
   This specification uses the Augmented Backus-Naur Form (ABNF) notation of
   <xref target="RFC5234"/> with a list extension, defined in
   <xref target="abnf.extension"/>, 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
   operators expanded to standard ABNF notation.
</t>
<t>
   As a convention, ABNF rule names prefixed with "obs-" denote
   "obsolete" grammar rules that appear for historical reasons.
</t>
<t anchor="core.rules">
  <x:anchor-alias value="ALPHA"/>
  <x:anchor-alias value="CR"/>
  <x:anchor-alias value="CRLF"/>
  <x:anchor-alias value="CTL"/>
  <x:anchor-alias value="DIGIT"/>
  <x:anchor-alias value="DQUOTE"/>
  <x:anchor-alias value="HEXDIG"/>
  <x:anchor-alias value="HTAB"/>
  <x:anchor-alias value="LF"/>
  <x:anchor-alias value="OCTET"/>
  <x:anchor-alias value="SP"/>
  <x:anchor-alias value="CHAR"/>
  <x:anchor-alias value="VCHAR"/>
  The following core rules are included by
  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
  DIGIT (decimal 0-9), DQUOTE (double quote),
  HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
  OCTET (any 8-bit sequence of data), SP (space), and
  VCHAR (any visible US-ASCII character).
  <cref>Range also uses CHAR, which is probably a bug.</cref>
</t>
<t anchor="imported.rules">
  <x:anchor-alias value="obs-fold"/>
  <x:anchor-alias value="protocol-name"/>
  <x:anchor-alias value="protocol-version"/>
  <x:anchor-alias value="request-target"/>
  The rules below are defined in <xref target="Messaging"/>:
</t>
<figure><artwork type="abnf2616">
  <x:ref>obs-fold</x:ref>         = &lt;obs-fold, see <xref target="line.folding"/>&gt;
  <x:ref>protocol-name</x:ref>    = &lt;protocol-name, see <xref target="header.upgrade"/>&gt;
  <x:ref>protocol-version</x:ref> = &lt;protocol-version, see <xref target="header.upgrade"/>&gt;
  <x:ref>request-target</x:ref>   = &lt;request-target, see <xref target="request.target"/>&gt;
</artwork></figure>
<t>
   This specification uses the terms
   "character",
   "character encoding scheme",
   "charset", and
   "protocol element"
   as they are defined in <xref target="RFC6365"/>.
</t>
</section>
</section>

<section title="Architecture" anchor="architecture">
<t>
   HTTP was created for the World Wide Web (WWW) architecture
   and has evolved over time to support the scalability needs of a worldwide
   hypertext system. Much of that architecture is reflected in the terminology
   and syntax productions used to define HTTP.
</t>

<section title="Client/Server Messaging" anchor="operation">
<iref primary="true" item="client"/>
<iref primary="true" item="server"/>
<iref primary="true" item="connection"/>
<t>
   HTTP is a stateless request/response protocol that operates by exchanging
   <x:dfn>messages</x:dfn> (<xref target="http.message"/>) across a reliable
   transport- or session-layer
   "<x:dfn>connection</x:dfn>" (<xref target="connection.management"/>).
   An HTTP "<x:dfn>client</x:dfn>" is a program that establishes a connection
   to a server for the purpose of sending one or more HTTP requests.
   An HTTP "<x:dfn>server</x:dfn>" is a program that accepts connections
   in order to service HTTP requests by sending HTTP responses.
</t>
<iref primary="true" item="user agent"/>
<iref primary="true" item="origin server"/>
<iref primary="true" item="browser"/>
<iref primary="true" item="spider"/>
<iref primary="true" item="sender"/>
<iref primary="true" item="recipient"/>
<t>
   The terms "client" and "server" refer only to the roles that
   these programs perform for a particular connection.  The same program
   might act as a client on some connections and a server on others.
   The term "<x:dfn>user agent</x:dfn>" refers to any of the various
   client programs that initiate a request, including (but not limited to)
   browsers, spiders (web-based robots), command-line tools, custom
   applications, and mobile apps.
   The term "<x:dfn>origin server</x:dfn>" refers to the program that can
   originate authoritative responses for a given target resource.
   The terms "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" refer to
   any implementation that sends or receives a given message, respectively.
</t>
<t>
   HTTP relies upon the Uniform Resource Identifier (URI)
   standard <xref target="RFC3986"/> to indicate the target resource
   (<xref target="target.resource"/>) and relationships between resources.
</t>
<t>
   Most HTTP communication consists of a retrieval request (GET) for
   a representation of some resource identified by a URI.  In the
   simplest case, this might be accomplished via a single bidirectional
   connection (===) between the user agent (UA) and the origin server (O).
</t>
<figure><artwork type="drawing">
         request   &gt;
    <x:highlight>UA</x:highlight> ======================================= <x:highlight>O</x:highlight>
                                &lt;   response
</artwork></figure>
<iref primary="true" item="message"/>
<iref primary="true" item="request"/>
<iref primary="true" item="response"/>
<t>
   A client sends an HTTP request to a server in the form of a <x:dfn>request</x:dfn>
   message, beginning with a request-line that includes a method, URI, and
   protocol version (<xref target="request.line"/>),
   followed by header fields containing
   request modifiers, client information, and representation metadata
   (<xref target="header.fields"/>),
   an empty line to indicate the end of the header section, and finally
   a message body containing the payload body (if any,
   <xref target="message.body"/>).
</t>
<t>
   A server responds to a client's request by sending one or more HTTP
   <x:dfn>response</x:dfn>
   messages, each beginning with a status line that
   includes the protocol version, a success or error code, and textual
   reason phrase (<xref target="status.line"/>),
   possibly followed by header fields containing server
   information, resource metadata, and representation metadata
   (<xref target="header.fields"/>),
   an empty line to indicate the end of the header section, and finally
   a message body containing the payload body (if any,
   <xref target="message.body"/>).
</t>
<t>
   A connection might be used for multiple request/response exchanges,
   as defined in <xref target="persistent.connections"/>.
</t>
<t>
   The following example illustrates a typical message exchange for a
   GET request (<xref target="GET"/>) on the URI "http://www.example.com/hello.txt":
</t>
<figure><preamble>
Client request:
</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

</artwork></figure>
<figure><preamble>
Server response:
</preamble><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: <x:length-of target="exbody"/>
Vary: Accept-Encoding
Content-Type: text/plain

<x:span anchor="exbody">Hello World! My payload includes a trailing CRLF.
</x:span></artwork>
</figure>
</section>

<section title="Intermediaries" anchor="intermediaries">
<iref primary="true" item="intermediary"/>
<t>
   HTTP enables the use of intermediaries to satisfy requests through
   a chain of connections.  There are three common forms of HTTP
   <x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel.  In some cases,
   a single intermediary might act as an origin server, proxy, gateway,
   or tunnel, switching behavior based on the nature of each request.
</t>
<figure><artwork type="drawing">
         &gt;             &gt;             &gt;             &gt;
    <x:highlight>UA</x:highlight> =========== <x:highlight>A</x:highlight> =========== <x:highlight>B</x:highlight> =========== <x:highlight>C</x:highlight> =========== <x:highlight>O</x:highlight>
               &lt;             &lt;             &lt;             &lt;
</artwork></figure>
<t>
   The figure above shows three intermediaries (A, B, and C) between the
   user agent and origin server. A request or response message that
   travels the whole chain will pass through four separate connections.
   Some HTTP communication options
   might apply only to the connection with the nearest, non-tunnel
   neighbor, only to the endpoints of the chain, or to all connections
   along the chain. Although the diagram is linear, each participant might
   be engaged in multiple, simultaneous communications. For example, B
   might be receiving requests from many clients other than A, and/or
   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
   different path of connections, often based on dynamic configuration for
   load balancing.   
</t>
<t>
<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
   The terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>" are
   used to describe directional requirements in relation to the message flow:
   all messages flow from upstream to downstream.
   The terms "inbound" and "outbound" are used to describe directional
   requirements in relation to the request route:
   "<x:dfn>inbound</x:dfn>" means toward the origin server and
   "<x:dfn>outbound</x:dfn>" means toward the user agent.
</t>
<t><iref primary="true" item="proxy"/>
   A "<x:dfn>proxy</x:dfn>" is a message-forwarding agent that is selected by the
   client, usually via local configuration rules, to receive requests
   for some type(s) of absolute URI and attempt to satisfy those
   requests via translation through the HTTP interface.  Some translations
   are minimal, such as for proxy requests for "http" URIs, whereas
   other requests might require translation to and from entirely different
   application-level protocols. Proxies are often used to group an
   organization's HTTP requests through a common intermediary for the
   sake of security, annotation services, or shared caching. Some proxies
   are designed to apply transformations to selected messages or payloads
   while they are being forwarded, as described in
   <xref target="message.transformations"/>.
</t>
<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
<iref primary="true" item="accelerator"/>
   A "<x:dfn>gateway</x:dfn>" (a.k.a. "<x:dfn>reverse proxy</x:dfn>") is an
   intermediary that acts as an origin server for the outbound connection but
   translates received requests and forwards them inbound to another server or
   servers. Gateways are often used to encapsulate legacy or untrusted
   information services, to improve server performance through
   "<x:dfn>accelerator</x:dfn>" caching, and to enable partitioning or load
   balancing of HTTP services across multiple machines.
</t>
<t>
   All HTTP requirements applicable to an origin server
   also apply to the outbound communication of a gateway.
   A gateway communicates with inbound servers using any protocol that
   it desires, including private extensions to HTTP that are outside
   the scope of this specification.  However, an HTTP-to-HTTP gateway
   that wishes to interoperate with third-party HTTP servers ought to conform
   to user agent requirements on the gateway's inbound connection.
</t>
<t><iref primary="true" item="tunnel"/>
   A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections
   without changing the messages. Once active, a tunnel is not
   considered a party to the HTTP communication, though the tunnel might
   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
   extend a virtual connection through an intermediary, such as when
   Transport Layer Security (TLS, <xref target="RFC5246"/>) is used to
   establish confidential communication through a shared firewall proxy.
</t>
<t>
   The above categories for intermediary only consider those acting as
   participants in the HTTP communication.  There are also intermediaries
   that can act on lower layers of the network protocol stack, filtering or
   redirecting HTTP traffic without the knowledge or permission of message
   senders. Network intermediaries are indistinguishable (at a protocol level)
   from a man-in-the-middle attack, often introducing security flaws or
   interoperability problems due to mistakenly violating HTTP semantics.
</t>
<t><iref primary="true" item="interception proxy"/>
<iref primary="true" item="transparent proxy"/>
<iref primary="true" item="captive portal"/>
   For example, an
   "<x:dfn>interception proxy</x:dfn>" <xref target="RFC3040"/> (also commonly
   known as a "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/> or
   "<x:dfn>captive portal</x:dfn>")
   differs from an HTTP proxy because it is not selected by the client.
   Instead, an interception proxy filters or redirects outgoing TCP port 80
   packets (and occasionally other common port traffic).
   Interception proxies are commonly found on public network access points,
   as a means of enforcing account subscription prior to allowing use of
   non-local Internet services, and within corporate firewalls to enforce
   network usage policies.
</t>
<t>
   HTTP is defined as a stateless protocol, meaning that each request message
   can be understood in isolation.  Many implementations depend on HTTP's
   stateless design in order to reuse proxied connections or dynamically
   load balance requests across multiple servers.  Hence, a server &MUST-NOT;
   assume that two requests on the same connection are from the same user
   agent unless the connection is secured and specific to that agent.
   Some non-standard HTTP extensions (e.g., <xref target="RFC4559"/>) have
   been known to violate this requirement, resulting in security and
   interoperability problems.
</t>
</section>

<section title="Caches" anchor="caches">
<iref primary="true" item="cache"/>
<t>
   A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the
   subsystem that controls its message storage, retrieval, and deletion.
   A cache stores cacheable responses in order to reduce the response
   time and network bandwidth consumption on future, equivalent
   requests. Any client or server &MAY; employ a cache, though a cache
   cannot be used by a server while it is acting as a tunnel.
</t>
<t>
   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
   applicable to that request. The following illustrates the resulting
   chain if B has a cached copy of an earlier response from O (via C)
   for a request that has not been cached by UA or A.
</t>
<figure><artwork type="drawing">
            &gt;             &gt;
       <x:highlight>UA</x:highlight> =========== <x:highlight>A</x:highlight> =========== <x:highlight>B</x:highlight> - - - - - - <x:highlight>C</x:highlight> - - - - - - <x:highlight>O</x:highlight>
                  &lt;             &lt;
</artwork></figure>
<t><iref primary="true" item="cacheable"/>
   A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of
   the response message for use in answering subsequent requests.
   Even when a response is cacheable, there might be additional
   constraints placed by the client or by the origin server on when
   that cached response can be used for a particular request. HTTP
   requirements for cache behavior and cacheable responses are
   defined in <xref target="caching.overview"/>.  
</t>
<t>
   There is a wide variety of architectures and configurations
   of caches deployed across the World Wide Web and
   inside large organizations. These include national hierarchies
   of proxy caches to save transoceanic bandwidth, collaborative systems that
   broadcast or multicast cache entries, archives of pre-fetched cache
   entries for use in off-line or high-latency environments, and so on.
</t>
</section>

<section title="Uniform Resource Identifiers" anchor="uri">
<iref primary="true" item="resource"/>
<t>
   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
   throughout HTTP as the means for identifying resources (<xref target="resources"/>).
   URI references are used to target requests, indicate redirects, and define
   relationships.
</t>
  <x:anchor-alias value="URI-reference"/>
  <x:anchor-alias value="absolute-URI"/>
  <x:anchor-alias value="relative-part"/>
  <x:anchor-alias value="authority"/>
  <x:anchor-alias value="uri-host"/>
  <x:anchor-alias value="port"/>
  <x:anchor-alias value="path"/>
  <x:anchor-alias value="path-abempty"/>
  <x:anchor-alias value="segment"/>
  <x:anchor-alias value="query"/>
  <x:anchor-alias value="fragment"/>
  <x:anchor-alias value="absolute-path"/>
  <x:anchor-alias value="partial-URI"/>
<t>
   The definitions of "URI-reference",
   "absolute-URI", "relative-part", "authority", "port", "host",
   "path-abempty", "segment", "query", and "fragment" are adopted from the
   URI generic syntax.
   An "absolute-path" rule is defined for protocol elements that can contain a
   non-empty path component. (This rule differs slightly from the path-abempty
   rule of RFC 3986, which allows for an empty path to be used in references,
   and path-absolute rule, which does not allow paths that begin with "//".)
   A "partial-URI" rule is defined for protocol elements
   that can contain a relative URI but not a fragment component.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"><!--exported production--></iref><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="absolute-path"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="fragment"/><iref primary="true" item="Grammar" subitem="segment"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="partial-URI"><!--exported production--></iref>
  <x:ref>URI-reference</x:ref> = &lt;URI-reference, see <xref target="RFC3986" x:fmt="," x:sec="4.1"/>&gt;
  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, see <xref target="RFC3986" x:fmt="," x:sec="4.3"/>&gt;
  <x:ref>relative-part</x:ref> = &lt;relative-part, see <xref target="RFC3986" x:fmt="," x:sec="4.2"/>&gt;
  <x:ref>authority</x:ref>     = &lt;authority, see <xref target="RFC3986" x:fmt="," x:sec="3.2"/>&gt;
  <x:ref>uri-host</x:ref>      = &lt;host, see <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>&gt;
  <x:ref>port</x:ref>          = &lt;port, see <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>&gt;
  <x:ref>path-abempty</x:ref>  = &lt;path-abempty, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
  <x:ref>segment</x:ref>       = &lt;segment, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
  <x:ref>query</x:ref>         = &lt;query, see <xref target="RFC3986" x:fmt="," x:sec="3.4"/>&gt;
  <x:ref>fragment</x:ref>      = &lt;fragment, see <xref target="RFC3986" x:fmt="," x:sec="3.5"/>&gt;
  
  <x:ref>absolute-path</x:ref> = 1*( "/" segment )
  <x:ref>partial-URI</x:ref>   = relative-part [ "?" query ]
</artwork></figure>
<t>
   Each protocol element in HTTP that allows a URI reference will indicate
   in its ABNF production whether the element allows any form of reference
   (URI-reference), only a URI in absolute form (absolute-URI), only the
   path and optional query components, or some combination of the above.
   Unless otherwise indicated, URI references are parsed
   relative to the effective request URI
   (<xref target="effective.request.uri"/>).
</t>
</section>

<section title="Resources" anchor="resources">
<t>
   The target of an HTTP request is called a "<x:dfn>resource</x:dfn>". 
   HTTP does not limit the nature of a resource; it merely
   defines an interface that might be used to interact with resources.
   Each resource is identified by a Uniform Resource Identifier (URI), as
   described in <xref target="uri"/>.
</t>
<t>
   One design goal of HTTP is to separate resource identification from
   request semantics, which is made possible by vesting the request
   semantics in the request method (<xref target="methods"/>) and a few
   request-modifying header fields (<xref target="request.header.fields"/>).
   If there is a conflict between the method semantics and any semantic
   implied by the URI itself, as described in <xref target="safe.methods"/>,
   the method semantics take precedence.
</t>
<t>
   IANA maintains the registry of URI Schemes <xref target="BCP115"/> at
   <eref target="https://www.iana.org/assignments/uri-schemes/"/>.
   <cref>Although requests might target any URI scheme, the following schemes are
   inherent to HTTP servers:</cref>
</t>
<texttable align="left" suppress-title="true">
   <ttcol>URI Scheme</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Reference</ttcol>

   <c>http</c>
   <c>Hypertext Transfer Protocol</c>
   <c><xref target="http.uri"/></c>

   <c>https</c>
   <c>Hypertext Transfer Protocol Secure</c>
   <c><xref target="https.uri"/></c>
</texttable>

<section title="http URI Scheme" anchor="http.uri">
  <x:anchor-alias value="http-URI"/>
  <iref item="http URI scheme" primary="true"/>
  <iref item="URI scheme" subitem="http" primary="true"/>
<t>
   The "http" URI scheme is hereby defined for the purpose of minting
   identifiers according to their association with the hierarchical
   namespace governed by a potential HTTP origin server listening for
   TCP (<xref target="RFC0793"/>) connections on a given port.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"><!--terminal production--></iref>
  <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
             [ "#" <x:ref>fragment</x:ref> ]
</artwork></figure>
<t>
   The origin server for an "http" URI is identified by the 
   <x:ref>authority</x:ref> component, which includes a host identifier
   and optional TCP port (<xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>).
   The hierarchical path component and optional query component serve as an
   identifier for a potential target resource within that origin server's name
   space. The optional fragment component allows for indirect identification
   of a secondary resource, independent of the URI scheme, as defined in
   <xref target="RFC3986" x:fmt="of" x:sec="3.5"/>.
</t>
<t>
   A sender &MUST-NOT; generate an "http" URI with an empty host identifier.
   A recipient that processes such a URI reference &MUST; reject it as invalid. 
</t>
<t>
   If the host identifier is provided as an IP address, the origin server is
   the listener (if any) on the indicated TCP port at that IP address.
   If host is a registered name, the registered name is an indirect identifier
   for use with a name resolution service, such as DNS, to find an address for
   that origin server.
   If the port subcomponent is empty or not given, TCP port 80 (the
   reserved port for WWW services) is the default.
</t>
<t>
   Note that the presence of a URI with a given authority component does not
   imply that there is always an HTTP server listening for connections on
   that host and port. Anyone can mint a URI. What the authority component
   determines is who has the right to respond authoritatively to requests that
   target the identified resource. The delegated nature of registered names
   and IP addresses creates a federated namespace, based on control over the
   indicated host and port, whether or not an HTTP server is present.
   See <xref target="establishing.authority"/> for security considerations
   related to establishing authority.
</t>
<t>
   When an "http" URI is used within a context that calls for access to the
   indicated resource, a client &MAY; attempt access by resolving
   the host to an IP address, establishing a TCP connection to that address
   on the indicated port, and sending an HTTP request message
   (<xref target="http.message"/>) containing the URI's identifying data
   to the server.
   If the server responds to that request with a non-interim HTTP response
   message, as described in <xref target="status.codes"/>, then that response
   is considered an authoritative answer to the client's request.
</t>
<t>
   Although HTTP is independent of the transport protocol, the "http"
   scheme is specific to TCP-based services because the name delegation
   process depends on TCP for establishing authority.
   An HTTP service based on some other underlying connection protocol
   would presumably be identified using a different URI scheme, just as
   the "https" scheme (below) is used for resources that require an
   end-to-end secured connection. Other protocols might also be used to
   provide access to "http" identified resources &mdash; it is only the
   authoritative interface that is specific to TCP.
</t>
<t>
   The URI generic syntax for authority also includes a deprecated
   userinfo subcomponent (<xref target="RFC3986" x:fmt="," x:sec="3.2.1"/>)
   for including user authentication information in the URI.  Some
   implementations make use of the userinfo component for internal
   configuration of authentication information, such as within command
   invocation options, configuration files, or bookmark lists, even
   though such usage might expose a user identifier or password.
   A sender &MUST-NOT; generate the userinfo subcomponent (and its "@"
   delimiter) when an "http" URI reference is generated within a message as a
   request target or header field value.
   Before making use of an "http" URI reference received from an untrusted
   source, a recipient &SHOULD; parse for userinfo and treat its presence as
   an error; it is likely being used to obscure the authority for the sake of
   phishing attacks.
</t>
</section>

<section title="https URI Scheme" anchor="https.uri">
   <x:anchor-alias value="https-URI"/>
   <iref item="https URI scheme"/>
   <iref item="URI scheme" subitem="https"/>
<t>
   The "https" URI scheme is hereby defined for the purpose of minting
   identifiers according to their association with the hierarchical
   namespace governed by a potential HTTP origin server listening to a
   given TCP port for TLS-secured connections (<xref target="RFC5246"/>).
</t>
<t>
   All of the requirements listed above for the "http" scheme are also
   requirements for the "https" scheme, except that TCP port 443 is the
   default if the port subcomponent is empty or not given,
   and the user agent &MUST; ensure that its connection to the origin
   server is secured through the use of strong encryption, end-to-end,
   prior to sending the first HTTP request.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"><!--terminal production--></iref>
  <x:ref>https-URI</x:ref> = "https:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
              [ "#" <x:ref>fragment</x:ref> ]
</artwork></figure>
<t>
   Note that the "https" URI scheme depends on both TLS and TCP for
   establishing authority.
   Resources made available via the "https" scheme have no shared
   identity with the "http" scheme even if their resource identifiers
   indicate the same authority (the same host listening to the same
   TCP port).  They are distinct namespaces and are considered to be
   distinct origin servers.  However, an extension to HTTP that is
   defined to apply to entire host domains, such as the Cookie protocol 
   <xref target="RFC6265"/>, can allow information
   set by one service to impact communication with other services
   within a matching group of host domains.
</t>
<t>
   The process for authoritative access to an "https" identified
   resource is defined in <xref target="RFC2818"/>.
</t>
</section>

<section title="http and https URI Normalization and Comparison" anchor="uri.comparison">
<t>
   Since the "http" and "https" schemes conform to the URI generic syntax,
   such URIs are normalized and compared according to the algorithm defined
   in <xref target="RFC3986" x:fmt="of" x:sec="6"/>, using the defaults
   described above for each scheme.
</t>
<t>
   If the port is equal to the default port for a scheme, the normal form is
   to omit the port subcomponent. When not being used in absolute form as the
   request target of an OPTIONS request, an empty path component is equivalent
   to an absolute path of "/", so the normal form is to provide a path of "/"
   instead. The scheme and host are case-insensitive and normally provided in
   lowercase; all other components are compared in a case-sensitive manner.
   Characters other than those in the "reserved" set are equivalent to their
   percent-encoded octets: the normal form is to not encode them
   (see Sections <xref target="RFC3986" x:fmt="number" x:sec="2.1"/> and
   <xref target="RFC3986" x:fmt="number" x:sec="2.2"/> of 
   <xref target="RFC3986"/>).
</t>
<t>
   For example, the following three URIs are equivalent:
</t>
<figure><artwork type="example">
   http://example.com:80/~smith/home.html
   http://EXAMPLE.com/%7Esmith/home.html
   http://EXAMPLE.com:/%7esmith/home.html
</artwork></figure>
</section>
</section>
</section>

<section title="Conformance" anchor="conformance">
<section title="Implementation Diversity" anchor="implementation-diversity">
<t>
   When considering the design of HTTP, it is easy to fall into a trap of
   thinking that all user agents are general-purpose browsers and all origin
   servers are large public websites. That is not the case in practice.
   Common HTTP user agents include household appliances, stereos, scales,
   firmware update scripts, command-line programs, mobile apps,
   and communication devices in a multitude of shapes and sizes.  Likewise,
   common HTTP origin servers include home automation units, configurable
   networking components, office machines, autonomous robots, news feeds,
   traffic cameras, ad selectors, and video-delivery platforms.
</t>
<t>
   The term "user agent" does not imply that there is a human user directly
   interacting with the software agent at the time of a request. In many
   cases, a user agent is installed or configured to run in the background
   and save its results for later inspection (or save only a subset of those
   results that might be interesting or erroneous). Spiders, for example, are
   typically given a start URI and configured to follow certain behavior while
   crawling the Web as a hypertext graph.
</t>
<t>
   The implementation diversity of HTTP means that not all user agents can
   make interactive suggestions to their user or provide adequate warning for
   security or privacy concerns. In the few cases where this
   specification requires reporting of errors to the user, it is acceptable
   for such reporting to only be observable in an error console or log file.
   Likewise, requirements that an automated action be confirmed by the user
   before proceeding might be met via advance configuration choices,
   run-time options, or simple avoidance of the unsafe action; confirmation
   does not imply any specific user interface or interruption of normal
   processing if the user has already made that choice.
</t>
</section>

<section title="Role-based Requirements" anchor="role-requirements">
<t>
   This specification targets conformance criteria according to the role of
   a participant in HTTP communication.  Hence, HTTP requirements are placed
   on senders, recipients, clients, servers, user agents, intermediaries,
   origin servers, proxies, gateways, or caches, depending on what behavior
   is being constrained by the requirement. Additional (social) requirements
   are placed on implementations, resource owners, and protocol element
   registrations when they apply beyond the scope of a single communication.
</t>
<t>
   The verb "generate" is used instead of "send" where a requirement
   differentiates between creating a protocol element and merely forwarding a
   received element downstream.
</t>
<t>
   An implementation is considered conformant if it complies with all of the
   requirements associated with the roles it partakes in HTTP.
</t>
<t>
   Conformance includes both the syntax and semantics of protocol
   elements. A sender &MUST-NOT; generate protocol elements that convey a
   meaning that is known by that sender to be false. A sender &MUST-NOT;
   generate protocol elements that do not match the grammar defined by the
   corresponding ABNF rules. Within a given message, a sender &MUST-NOT;
   generate protocol elements or syntax alternatives that are only allowed to
   be generated by participants in other roles (i.e., a role that the sender
   does not have for that message).
</t>
</section>

<section title="Parsing Elements" anchor="parsing-elements">
<t>
   When a received protocol element is parsed, the recipient &MUST; be able to
   parse any value of reasonable length that is applicable to the recipient's
   role and that matches the grammar defined by the corresponding ABNF rules.
   Note, however, that some received protocol elements might not be parsed.
   For example, an intermediary forwarding a message might parse a
   header-field into generic field-name and field-value components, but then
   forward the header field without further parsing inside the field-value.
</t>
<t>
   HTTP does not have specific length limitations for many of its protocol
   elements because the lengths that might be appropriate will vary widely,
   depending on the deployment context and purpose of the implementation.
   Hence, interoperability between senders and recipients depends on shared
   expectations regarding what is a reasonable length for each protocol
   element. Furthermore, what is commonly understood to be a reasonable length
   for some protocol elements has changed over the course of the past two
   decades of HTTP use and is expected to continue changing in the future.
</t>
<t>
   At a minimum, a recipient &MUST; be able to parse and process protocol
   element lengths that are at least as long as the values that it generates
   for those same protocol elements in other messages. For example, an origin
   server that publishes very long URI references to its own resources needs
   to be able to parse and process those same references when received as a
   request target.
</t>
</section>

<section title="Error Handling" anchor="error-handling">
<t>
   A recipient &MUST; interpret a received protocol element according to the
   semantics defined for it by this specification, including extensions to
   this specification, unless the recipient has determined (through experience
   or configuration) that the sender incorrectly implements what is implied by
   those semantics.
   For example, an origin server might disregard the contents of a received
   <x:ref>Accept-Encoding</x:ref> header field if inspection of the
   <x:ref>User-Agent</x:ref> header field indicates a specific implementation
   version that is known to fail on receipt of certain content codings.
</t>
<t>
   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
   protocol element from an invalid construct.  HTTP does not define
   specific error handling mechanisms except when they have a direct impact
   on security, since different applications of the protocol require
   different error handling strategies.  For example, a Web browser might
   wish to transparently recover from a response where the
   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
   whereas a systems control client might consider any form of error recovery
   to be dangerous.
</t>
</section>

<section title="Protocol Versioning" anchor="protocol.version">
<t>
   The HTTP version number consists of two decimal digits separated by a "."
   (period or decimal point). The first digit ("major version") indicates the
   HTTP messaging syntax, whereas the second digit ("minor version")
   indicates the highest minor version within that major version to which the
   sender is conformant and able to understand for future communication.
</t>
<t>
   The protocol version as a whole indicates the sender's conformance with
   the set of requirements laid out in that version's corresponding
   specification of HTTP.
<cref>
   For example, the version "HTTP/1.1" is defined by the combined
   specifications of this document, "HTTP Caching" <xref target="Caching"/>,
   and "HTTP/1.1 Messaging" <xref target="Messaging"/>.
</cref></t>
<t>
   The minor version advertises the sender's communication capabilities even
   when the sender is only using a backwards-compatible subset of the
   protocol, thereby letting the recipient know that more advanced features
   can be used in response (by servers) or in future requests (by clients).
</t>
<t>
   A client &SHOULD; send a request version equal to the highest
   version to which the client is conformant and
   whose major version is no higher than the highest version supported
   by the server, if this is known.  A client &MUST-NOT; send a
   version to which it is not conformant.
</t>
<t>
   A client &MAY; send a lower request version if it is known that
   the server incorrectly implements the HTTP specification, but only
   after the client has attempted at least one normal request and determined
   from the response status code or header fields (e.g., <x:ref>Server</x:ref>) that
   the server improperly handles higher request versions.
</t>
<t>
   A server &SHOULD; send a response version equal to the highest version to
   which the server is conformant that has a major version less than or equal
   to the one received in the request.
   A server &MUST-NOT; send a version to which it is not conformant.
   A server can send a <x:ref>505 (HTTP Version Not Supported)</x:ref>
   response if it wishes, for any reason, to refuse service of the client's
   major protocol version.
</t>
<t>
   HTTP's major version number is incremented when an incompatible message
   syntax is introduced. The minor number is incremented when changes made to
   the protocol have the effect of adding to the message semantics or
   implying additional capabilities of the sender.
</t>
<t>
   When an HTTP message is received with a major version number that the
   recipient implements, but a higher minor version number than what the
   recipient implements, the recipient &SHOULD; process the message as if it
   were in the highest minor version within that major version to which the
   recipient is conformant. A recipient can assume that a message with a
   higher minor version, when sent to a recipient that has not yet indicated
   support for that higher version, is sufficiently backwards-compatible to be
   safely processed by any implementation of the same major version.
</t>
<t><cref>
   When a major version of HTTP does not define any minor versions, the minor
   version "0" is implied and ought to be used when referring to that
   protocol within a protocol element that requires sending a minor version.
</cref></t>
</section>
</section>

<section title="Message Abstraction" anchor="message.abstraction">
<t><cref>
   Each major version of HTTP defines its own syntax for the inclusion of
   information in messages. Nevertheless, a common abstraction is that a
   message includes some form of envelope/framing, a potential set of named
   data fields, and a potential body. This section defines the abstraction
   for message fields as field-name and field-value pairs.
</cref></t>

<section title="Field Names" anchor="field.names">
  <x:anchor-alias value="field-name"/>
<t>
   Header fields are key:value pairs that can be used to communicate data about
   the message, its payload, the target resource, or the connection
   (i.e., control data).
</t>
<t>
   The requirements for header field names are defined in
   <xref target="BCP90"/>.
</t>
<t>
   The field-name token labels the corresponding field-value as having the
   semantics defined by that header field.  For example, the <x:ref>Date</x:ref>
   header field is defined in <xref target="header.date"/> as containing the origination
   timestamp for the message in which it appears.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="field-name"/>
  <x:ref>field-name</x:ref>     = <x:ref>token</x:ref>
</artwork></figure>
<t>
   The interpretation of a header field does not change between minor
   versions of the same major HTTP version, though the default behavior of a
   recipient in the absence of such a field can change. Unless specified
   otherwise, header fields are defined for all versions of HTTP.
   In particular, the <x:ref>Host</x:ref> and <x:ref>Connection</x:ref>
   header fields ought to be implemented by all HTTP/1.x implementations
   whether or not they advertise conformance with HTTP/1.1.
</t>
<t>
   New header fields can be introduced without changing the protocol version
   if their defined semantics allow them to be safely ignored by recipients
   that do not recognize them. Header field extensibility is discussed in
   <xref target="field.extensibility"/>.
</t>
<t>
   The following field names are defined by this document:
</t>
<?BEGININC build/draft-ietf-httpbis-semantics-latest.iana-headers ?>
<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
<texttable align="left"
           suppress-title="true"
           anchor="iana.header.registration.table">
   <ttcol>Header Field Name</ttcol>
   <ttcol>Protocol</ttcol>
   <ttcol>Status</ttcol>
   <ttcol>Reference</ttcol>

   <c>Accept</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.accept"/>
   </c>
   <c>Accept-Charset</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.accept-charset"/>
   </c>
   <c>Accept-Encoding</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.accept-encoding"/>
   </c>
   <c>Accept-Language</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.accept-language"/>
   </c>
   <c>Accept-Ranges</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.accept-ranges"/>
   </c>
   <c>Allow</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.allow"/>
   </c>
   <c>Authorization</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.authorization"/>
   </c>
   <c>Content-Encoding</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-encoding"/>
   </c>
   <c>Content-Language</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-language"/>
   </c>
   <c>Content-Length</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-length"/>
   </c>
   <c>Content-Location</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-location"/>
   </c>
   <c>Content-Range</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-range"/>
   </c>
   <c>Content-Type</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.content-type"/>
   </c>
   <c>Date</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.date"/>
   </c>
   <c>ETag</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.etag"/>
   </c>
   <c>Expect</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.expect"/>
   </c>
   <c>From</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.from"/>
   </c>
   <c>Host</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.host"/>
   </c>
   <c>If-Match</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.if-match"/>
   </c>
   <c>If-Modified-Since</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.if-modified-since"/>
   </c>
   <c>If-None-Match</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.if-none-match"/>
   </c>
   <c>If-Range</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.if-range"/>
   </c>
   <c>If-Unmodified-Since</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.if-unmodified-since"/>
   </c>
   <c>Last-Modified</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.last-modified"/>
   </c>
   <c>Location</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.location"/>
   </c>
   <c>Max-Forwards</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.max-forwards"/>
   </c>
   <c>Proxy-Authenticate</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.proxy-authenticate"/>
   </c>
   <c>Proxy-Authorization</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.proxy-authorization"/>
   </c>
   <c>Range</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.range"/>
   </c>
   <c>Referer</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.referer"/>
   </c>
   <c>Retry-After</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.retry-after"/>
   </c>
   <c>Server</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.server"/>
   </c>
   <c>Trailer</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.trailer"/>
   </c>
   <c>User-Agent</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.user-agent"/>
   </c>
   <c>Vary</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.vary"/>
   </c>
   <c>Via</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.via"/>
   </c>
   <c>WWW-Authenticate</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="header.www-authenticate"/>
   </c>
</texttable>
<!--(END)-->

<?ENDINC build/draft-ietf-httpbis-semantics-latest.iana-headers ?>

<section title="Field Name Registry" anchor="field.name.registry">
<t>
   HTTP header fields are registered within the "Message Headers" registry
   located at <eref target="https://www.iana.org/assignments/message-headers"/>,
   as defined by <xref target="BCP90"/>, with the protocol "http".
</t>
</section>

<section title="Field Extensibility" anchor="field.extensibility">
<t>
   Header fields are fully extensible: there is no limit on the
   introduction of new field names, each presumably defining new semantics,
   nor on the number of header fields used in a given message.  Existing
   fields are defined in each part of this specification and in many other
   specifications outside this document set.
</t>
<t>
   New header fields can be defined such that, when they are understood by a
   recipient, they might override or enhance the interpretation of previously
   defined header fields, define preconditions on request evaluation, or
   refine the meaning of responses.
</t>
<t>
   A proxy &MUST; forward unrecognized header fields unless the
   field-name is listed in the <x:ref>Connection</x:ref> header field
   (<xref target="header.connection"/>) or the proxy is specifically
   configured to block, or otherwise transform, such fields.
   Other recipients &SHOULD; ignore unrecognized header fields.
   These requirements allow HTTP's functionality to be enhanced without
   requiring prior update of deployed intermediaries.
</t>
<t>
   All defined header fields ought to be registered with IANA in the
   "Message Headers" registry.
</t>
</section>

<section title="Considerations for New Fields" anchor="considerations.for.new.header.fields">
<t>   
   Authors of specifications defining new fields are
   advised to keep the name as short as practical and not to prefix the name
   with "X-" unless the header field will never be used on the Internet.
   (The "X-" prefix idiom has been extensively misused in practice; it was
   intended to only be used as a mechanism for avoiding name collisions inside
   proprietary software or intranet processing, since the prefix would ensure
   that private names never collide with a newly registered Internet name; see
   <xref target="BCP178"/> for further information).
</t>
<t>
   Authors of specifications defining new header fields are advised to consider
   documenting:
</t>
<ul>
  <li>
    <t>Whether the field is a single value or whether it can be a list
    (delimited by commas; see <xref target="header.fields"/>).</t>
    <t>If it does not use the list syntax, document how to treat messages
    where the field occurs multiple times (a sensible default would
    be to ignore the field, but this might not always be the right
    choice).</t>
    <t>Note that intermediaries and software libraries might combine
    multiple header field instances into a single one, despite the
    field's definition not allowing the list syntax. A robust format enables
    recipients to discover these situations (good example: "Content-Type",
    as the comma can only appear inside quoted strings;
    bad example: "Location", as a comma can occur inside a URI).</t>
  </li>
  <li><t>Under what conditions the header field can be used; e.g., only in
    responses or requests, in all messages, only on responses to a
    particular request method, etc.</t></li>
  <li><t>Whether the field should be stored by origin servers that
    understand it upon a PUT request.</t></li>
  <li><t>Whether the field semantics are further refined by the context,
    such as by existing request methods or status codes.</t></li>
  <li><t>Whether it is appropriate to list the field-name in the
    <x:ref>Connection</x:ref> header field (i.e., if the header field is to
    be hop-by-hop; see <xref target="header.connection"/>).</t></li>
  <li><t>Under what conditions intermediaries are allowed to insert,
    delete, or modify the field's value.</t></li>
  <li><t>Whether it is appropriate to list the field-name in a
    <x:ref>Vary</x:ref> response header field (e.g., when the request header
    field is used by an origin server's content selection algorithm; see
    <xref target="header.vary"/>).</t></li>
  <li><t>Whether the header field is useful or allowable in trailers (see
    <xref target="chunked.encoding"/>).</t></li>
  <li><t>Whether the header field ought to be preserved across redirects.</t></li>
  <li><t>Whether it introduces any additional security considerations, such
    as disclosure of privacy-related data.</t></li>
</ul>
</section>
</section>

<section title="Field Values" anchor="field.values">
  <x:anchor-alias value="field-value"/>
  <x:anchor-alias value="field-content"/>
  <x:anchor-alias value="field-vchar"/>
<t>
   This specification does not use ABNF rules to define each
   "Field-Name: Field Value" pair, as was done in earlier editions.
   Instead, this specification uses ABNF rules that are named according to
   each registered field name, wherein the rule defines the valid grammar for
   that field's corresponding field values (i.e., after the field-value
   has been extracted by a generic field parser).
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-vchar"/><iref primary="true" item="Grammar" subitem="field-content"/>
  <x:ref>field-value</x:ref>    = *( <x:ref>field-content</x:ref> / <x:ref>obs-fold</x:ref> )
  <x:ref>field-content</x:ref>  = <x:ref>field-vchar</x:ref> [ 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> ) <x:ref>field-vchar</x:ref> ]
  <x:ref>field-vchar</x:ref>    = <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref>
</artwork></figure>
<t>
   Historically, HTTP header field values could be extended over multiple
   lines by preceding each extra line with at least one space or horizontal
   tab (<x:ref>obs-fold</x:ref>).
   <cref>This document assumes that any such <x:ref>obs-fold</x:ref> has been replaced with one or more
   <x:ref>SP</x:ref> octets prior to interpreting the field value,
   as described in <xref target="line.folding"/>.</cref>
</t>
<t>
   Historically, HTTP has allowed field content with text in the ISO&nbhy;8859&nbhy;1
   charset <xref target="ISO-8859-1"/>, supporting other charsets only
   through use of <xref target="RFC2047"/> encoding.
   In practice, most HTTP header field values use only a subset of the
   US-ASCII charset <xref target="USASCII"/>. Newly defined
   header fields &SHOULD; limit their field values to US&nbhy;ASCII octets.
   A recipient &SHOULD; treat other octets in field content (obs&nbhy;text) as
   opaque data.
</t>

<section title="Field Order" anchor="field.order">
<t>
   The order in which header fields with differing field names are
   received is not significant. However, it is good practice to send
   header fields that contain control data first, such as <x:ref>Host</x:ref>
   on requests and <x:ref>Date</x:ref> on responses, so that implementations
   can decide when not to handle a message as early as possible.
   A server &MUST-NOT; apply a request to the target resource until the entire
   request header section is received, since later header fields might include
   conditionals, authentication credentials, or deliberately misleading
   duplicate header fields that would impact request processing.
</t>
<t>
   A sender &MUST-NOT; generate multiple header fields with the same field
   name in a message unless either the entire field value for that
   header field is defined as a comma-separated list [i.e., #(values)]
   or the header field is a well-known exception (as noted below).
</t>
<t>
   A recipient &MAY; combine multiple header fields with the same field name
   into one "field-name: field-value" pair, without changing the semantics of
   the message, by appending each subsequent field value to the combined
   field value in order, separated by a comma. The order in which
   header fields with the same field name are received is therefore
   significant to the interpretation of the combined field value;
   a proxy &MUST-NOT; change the order of these field values when
   forwarding a message.
</t>
<aside>
  <t>
   &Note; In practice, the "Set-Cookie" header field (<xref target="RFC6265"/>)
   often appears multiple times in a response message and does not use the
   list syntax, violating the above requirements on multiple header fields
   with the same name. Since it cannot be combined into a single field-value,
   recipients ought to handle "Set-Cookie" as a special case while processing
   header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.)
  </t>
</aside>
</section>

<section title="Field Limits" anchor="field.limits">
<t>
   HTTP does not place a predefined limit on the length of each header field
   or on the length of the header section as a whole, as described in
   <xref target="conformance"/>. Various ad hoc limitations on individual
   header field length are found in practice, often depending on the specific
   field semantics.
</t>
<t>
   A server that receives a request header field, or set of fields, larger
   than it wishes to process &MUST; respond with an appropriate
   <x:ref>4xx (Client Error)</x:ref> status code. Ignoring such header fields
   would increase the server's vulnerability to request smuggling attacks
   (<xref target="request.smuggling"/>).
</t>
<t>
   A client &MAY; discard or truncate received header fields that are larger
   than the client wishes to process if the field semantics are such that the
   dropped value(s) can be safely ignored without changing the
   message framing or response semantics.
</t>
</section>

<section title="Field Value Components" anchor="field.components">
<t anchor="rule.token.separators">
  <x:anchor-alias value="tchar"/>
  <x:anchor-alias value="token"/>
  <iref item="Delimiters"/>
   Most HTTP header field values are defined using common syntax components
   (token, quoted-string, and comment) separated by whitespace or specific
   delimiting characters. Delimiters are chosen from the set of US-ASCII
   visual characters not allowed in a <x:ref>token</x:ref>
   (DQUOTE and "(),/:;&lt;=>?@[\]{}").
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/>
  <x:ref>token</x:ref>          = 1*<x:ref>tchar</x:ref>
<!--
  NOTE: the definition of tchar and the prose above about special characters need to match!
 -->
  <x:ref>tchar</x:ref>          = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / <x:ref>DIGIT</x:ref> / <x:ref>ALPHA</x:ref>
                 ; any <x:ref>VCHAR</x:ref>, except delimiters
</artwork></figure>
<t anchor="rule.quoted-string">
  <x:anchor-alias value="quoted-string"/>
  <x:anchor-alias value="qdtext"/>
  <x:anchor-alias value="obs-text"/>
   A string of text is parsed as a single value if it is quoted using
   double-quote marks.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/>
  <x:ref>quoted-string</x:ref>  = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref>
  <x:ref>qdtext</x:ref>         = <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> /%x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref>
  <x:ref>obs-text</x:ref>       = %x80-FF
</artwork></figure>
<t anchor="rule.comment">
  <x:anchor-alias value="comment"/>
  <x:anchor-alias value="ctext"/>
   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
  <x:ref>comment</x:ref>        = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")"
  <x:ref>ctext</x:ref>          = <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> / %x21-27 / %x2A-5B / %x5D-7E / <x:ref>obs-text</x:ref>
</artwork></figure>
<t anchor="rule.quoted-pair">
  <x:anchor-alias value="quoted-pair"/>
   The backslash octet ("\") can be used as a single-octet
   quoting mechanism within quoted-string and comment constructs.
   Recipients that process the value of a quoted-string &MUST; handle a
   quoted-pair as if it were replaced by the octet following the backslash.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-pair"/>
  <x:ref>quoted-pair</x:ref>    = "\" ( <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> )
</artwork></figure>
<t>
   A sender &SHOULD-NOT; generate a quoted-pair in a quoted-string except
   where necessary to quote DQUOTE and backslash octets occurring within that
   string.
   A sender &SHOULD-NOT; generate a quoted-pair in a comment except
   where necessary to quote parentheses ["(" and ")"] and backslash octets
   occurring within that comment.
</t>
</section>

<section title="Designing New Field Values" anchor="new.field.values">
<t>
   New header field values typically have their syntax defined using ABNF
   (<xref target="RFC5234"/>), using the extension defined in <xref target="abnf.extension"/>
   as necessary, and are usually constrained to the range of US-ASCII characters.
   Header fields needing a greater range of characters can use an encoding
   such as the one defined in <xref target="RFC5987"/>. 
</t>
<t>
   Leading and trailing whitespace in raw field values is removed upon field
   parsing (<xref target="field.parsing"/>). Field definitions where leading or trailing
   whitespace in values is significant will have to use a container syntax such
   as quoted-string (<xref target="field.components"/>).
</t>
<t>
   Because commas (",") are used as a generic delimiter between field-values,
   they need to be treated with care if they are allowed in the field-value.
   Typically, components that might contain a comma are protected with
   double-quotes using the quoted-string ABNF production.
</t>
<t>
   For example, a textual date and a URI (either of which might contain a comma)
   could be safely carried in field-values like these:
</t>
<figure><artwork type="example">
  Example-URI-Field: "http://example.com/a.html,foo",
                     "http://without-a-comma.example.com/"
  Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
</artwork></figure>
<t>
   Note that double-quote delimiters almost always are used with the
   quoted-string production; using a different syntax inside double-quotes
   will likely cause unnecessary confusion.
</t>
<t>
   Many header fields use a format including (case-insensitively) named
   parameters (for instance, <x:ref>Content-Type</x:ref>, defined in
   <xref target="header.content-type"/>). Allowing both unquoted (token) and quoted
   (quoted-string) syntax for the parameter value enables recipients to use
   existing parser components. When allowing both forms, the meaning of a
   parameter value ought to be independent of the syntax used for it (for an
   example, see the notes on parameter handling for media types in
   <xref target="media.type"/>).
</t>
</section>
</section>

<section title="Whitespace" anchor="whitespace">
  <x:anchor-alias value="BWS"/>
  <x:anchor-alias value="OWS"/>
  <x:anchor-alias value="RWS"/>
<t>
   This specification uses three rules to denote the use of linear
   whitespace: OWS (optional whitespace), RWS (required whitespace), and
   BWS ("bad" whitespace).
</t>
<t>
   The OWS rule is used where zero or more linear whitespace octets might
   appear. For protocol elements where optional whitespace is preferred to
   improve readability, a sender &SHOULD; generate the optional whitespace
   as a single SP; otherwise, a sender &SHOULD-NOT; generate optional
   whitespace except as needed to white out invalid or unwanted protocol
   elements during in-place message filtering.
</t>
<t>
   The RWS rule is used when at least one linear whitespace octet is required
   to separate field tokens. A sender &SHOULD; generate RWS as a single SP.
</t>
<t>
   The BWS rule is used where the grammar allows optional whitespace only for
   historical reasons. A sender &MUST-NOT; generate BWS in messages.
   A recipient &MUST; parse for such bad whitespace and remove it before
   interpreting the protocol element.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/>
  <x:ref>OWS</x:ref>            = *( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> )
                 ; optional whitespace
  <x:ref>RWS</x:ref>            = 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> )
                 ; required whitespace
  <x:ref>BWS</x:ref>            = <x:ref>OWS</x:ref>
                 ; "bad" whitespace
</artwork></figure>
</section>

<section title="Trailer" anchor="header.trailer">
  <iref primary="true" item="Trailer header field" x:for-anchor=""/>
  <x:anchor-alias value="Trailer"/>
<t><cref>
   The "Trailer" header field in a message indicates fields that the sender
   anticipates sending after the message header block (i.e., during or after
   the payload is sent). This is typically used to supply metadata that might
   be dynamically generated while the data is sent, such as a message
   integrity check, digital signature, or post-processing status.
</cref></t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="false" item="Grammar" subitem="field-name"/>
  <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
</artwork></figure>
<t><cref>
   How, where, and when trailer fields might be sent depends on both the
   protocol in use (HTTP version and/or transfer coding) and the semantics
   of each named header field. Many header fields cannot be processed outside
   the header section because their evaluation is necessary for message
   routing, authentication, or configuration prior to receiving the
   representation data.
</cref></t>
</section>
</section>

<section title="Message Routing" anchor="message.routing">
<t>
   HTTP request message routing is determined by each client based on the
   target resource, the client's proxy configuration, and
   establishment or reuse of an inbound connection.  The corresponding
   response routing follows the same connection chain back to the client.
</t>

<section title="Identifying a Target Resource" anchor="target.resource">
  <iref primary="true" item="target resource"/>
  <iref primary="true" item="target URI"/>
  <x:anchor-alias value="target resource"/>
  <x:anchor-alias value="target URI"/>
<t>
   HTTP is used in a wide variety of applications, ranging from
   general-purpose computers to home appliances.  In some cases,
   communication options are hard-coded in a client's configuration.
   However, most HTTP clients rely on the same resource identification
   mechanism and configuration techniques as general-purpose Web browsers.
</t>
<t>
   HTTP communication is initiated by a user agent for some purpose.
   The purpose is a combination of request semantics
   and a target resource upon which to apply those
   semantics.  A URI reference (<xref target="uri"/>) is typically used as
   an identifier for the "<x:dfn>target resource</x:dfn>", which a user agent
   would resolve to its absolute form in order to obtain the
   "<x:dfn>target URI</x:dfn>".  The target URI
   excludes the reference's fragment component, if any,
   since fragment identifiers are reserved for client-side processing
   (<xref target="RFC3986" x:fmt="," x:sec="3.5"/>).
</t>
</section>

<section title="Routing Inbound" anchor="routing.inbound">
<t>
   Once the target URI is determined, a client needs to decide whether
   a network request is necessary to accomplish the desired semantics and,
   if so, where that request is to be directed.
</t>
<t>
   If the client has a cache <xref target="Caching"/> and the request can be
   satisfied by it, then the request is
   usually directed there first.
</t>
<t>
   If the request is not satisfied by a cache, then a typical client will
   check its configuration to determine whether a proxy is to be used to
   satisfy the request.  Proxy configuration is implementation-dependent,
   but is often based on URI prefix matching, selective authority matching,
   or both, and the proxy itself is usually identified by an "http" or
   "https" URI.  If a proxy is applicable, the client connects inbound by
   establishing (or reusing) a connection to that proxy.
</t>
<t>
   If no proxy is applicable, a typical client will invoke a handler routine,
   usually specific to the target URI's scheme, to connect directly
   to an authority for the target resource.  How that is accomplished is
   dependent on the target URI scheme and defined by its associated
   specification, similar to how this specification defines origin server
   access for resolution of the "http" (<xref target="http.uri"/>) and
   "https" (<xref target="https.uri"/>) schemes.
</t>
<t>
   HTTP requirements regarding connection management are defined in
   <xref target="connection.management"/>.
</t>
</section>

<section title="Effective Request URI" anchor="effective.request.uri">
  <iref primary="true" item="effective request URI"/>
  <x:anchor-alias value="effective request URI"/>
<t>
   Once an inbound connection is obtained,
   the client sends an HTTP request message (<xref target="http.message"/>).
</t>
<t><cref>
   Depending on the nature of the request, the client's target URI might be
   split into components and transmitted (or implied) within various parts of
   a request message. These parts are recombined by each recipient, in
   accordance with their local configuration and incoming connection context,
   to form an "<x:dfn>effective request URI</x:dfn>" for identifying the
   intended target resource with respect to that server.
   <xref target="h1.effective.request.uri"/> defines how a server
   determines the effective request URI for an HTTP/1.1 request.</cref>
</t>
<t>
   For a user agent, the effective request URI is the target URI.
</t>
<t>
   Once the effective request URI has been constructed, an origin server needs
   to decide whether or not to provide service for that URI via the connection
   in which the request was received. For example, the request might have been
   misdirected, deliberately or accidentally, such that the information within
   a received <x:ref>request-target</x:ref> or <x:ref>Host</x:ref> header
   field differs from the host or port upon which the connection has been
   made. If the connection is from a trusted gateway, that inconsistency might
   be expected; otherwise, it might indicate an attempt to bypass security
   filters, trick the server into delivering non-public content, or poison a
   cache. See <xref target="security.considerations"/> for security
   considerations regarding message routing.
</t>
</section>

<section title="Host" anchor="header.host">
  <iref primary="true" item="Host header field" x:for-anchor=""/>
  <x:anchor-alias value="Host"/>
<t>
   The "Host" header field in a request provides the host and port
   information from the target URI, enabling the origin
   server to distinguish among resources while servicing requests
   for multiple host names on a single IP address.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
  <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="uri"/>
</artwork></figure>
<t>
   A client &MUST; send a Host header field in all HTTP/1.1 request messages.
   If the target URI includes an authority component, then a client &MUST;
   send a field-value for Host that is identical to that authority
   component, excluding any userinfo subcomponent and its "@" delimiter
   (<xref target="http.uri"/>).
   If the authority component is missing or undefined for the target URI,
   then a client &MUST; send a Host header field with an empty field-value.
</t>
<t>
   Since the Host field-value is critical information for handling a request,
   a user agent &SHOULD; generate Host as the first header field following the
   request-line.
</t>
<t>
   For example, a GET request to the origin server for
   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
</t>
<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
GET /pub/WWW/ HTTP/1.1
Host: www.example.org
</artwork></figure>
<t>
   A client &MUST; send a Host header field in an HTTP/1.1 request even
   if the request-target is in the absolute-form, since this
   allows the Host information to be forwarded through ancient HTTP/1.0
   proxies that might not have implemented Host.
</t>
<t>
   When a proxy receives a request with an absolute-form of
   request-target, the proxy &MUST; ignore the received
   Host header field (if any) and instead replace it with the host
   information of the request-target.  A proxy that forwards such a request
   &MUST; generate a new Host field-value based on the received
   request-target rather than forward the received Host field-value.
</t>
<t>
   Since the Host header field acts as an application-level routing
   mechanism, it is a frequent target for malware seeking to poison
   a shared cache or redirect a request to an unintended server.
   An interception proxy is particularly vulnerable if it relies on
   the Host field-value for redirecting requests to internal
   servers, or for use as a cache key in a shared cache, without
   first verifying that the intercepted connection is targeting a
   valid IP address for that host.
</t>
<t>
   A server &MUST; respond with a <x:ref>400 (Bad Request)</x:ref> status code
   to any HTTP/1.1 request message that lacks a Host header field and
   to any request message that contains more than one Host header field
   or a Host header field with an invalid field-value.
</t>
</section>

<section title="Associating a Response to a Request" anchor="associating.response.to.request">
<t>
   HTTP does not include a request identifier for associating a given
   request message with its corresponding one or more response messages.
   Hence, it relies on the order of response arrival to correspond exactly
   to the order in which requests are made on the same connection.
   More than one response message per request only occurs when one or more
   informational responses (<x:ref>1xx</x:ref>, see <xref target="status.1xx"/>) precede a
   final response to the same request.
</t>
<t>
   A client that has more than one outstanding request on a connection &MUST;
   maintain a list of outstanding requests in the order sent and &MUST;
   associate each received response message on that connection to the highest
   ordered request that has not yet received a final (non-<x:ref>1xx</x:ref>)
   response.
</t>
</section>

<section title="Message Forwarding" anchor="message.forwarding">
<t>
   As described in <xref target="intermediaries"/>, intermediaries can serve
   a variety of roles in the processing of HTTP requests and responses.
   Some intermediaries are used to improve performance or availability.
   Others are used for access control or to filter content.
   Since an HTTP stream has characteristics similar to a pipe-and-filter
   architecture, there are no inherent limits to the extent an intermediary
   can enhance (or interfere) with either direction of the stream.
</t>
<t>
   An intermediary not acting as a tunnel &MUST; implement the
   <x:ref>Connection</x:ref> header field, as specified in
   <xref target="header.connection"/>, and exclude fields from being forwarded
   that are only intended for the incoming connection.
</t>
<t>
   An intermediary &MUST-NOT; forward a message to itself unless it is
   protected from an infinite request loop. In general, an intermediary ought
   to recognize its own server names, including any aliases, local variations,
   or literal IP addresses, and respond to such requests directly.
</t>
<t>
   An HTTP message can be parsed as a stream for incremental processing or
   forwarding downstream.  However, recipients cannot rely on incremental
   delivery of partial messages, since some implementations will buffer or
   delay message forwarding for the sake of network efficiency, security
   checks, or payload transformations.
</t>

<section title="Via" anchor="header.via">
  <iref primary="true" item="Via header field" x:for-anchor=""/>
  <x:anchor-alias value="pseudonym"/>
  <x:anchor-alias value="received-by"/>
  <x:anchor-alias value="received-protocol"/>
  <x:anchor-alias value="Via"/>
<t>
   The "Via" header field indicates the presence of intermediate protocols and
   recipients between the user agent and the server (on requests) or between
   the origin server and the client (on responses), similar to the
   "Received" header field in email
   (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>).
   Via can be used for tracking message forwards,
   avoiding request loops, and identifying the protocol capabilities of
   senders along the request/response chain.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
  <x:ref>Via</x:ref> = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref> [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )

  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
                      ; see <xref target="header.upgrade"/>
  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
</artwork></figure>
<t>
   Multiple Via field values represent each proxy or gateway that has
   forwarded the message. Each intermediary appends its own information
   about how the message was received, such that the end result is ordered
   according to the sequence of forwarding recipients.
</t>
<t>
   A proxy &MUST; send an appropriate Via header field, as described below, in
   each message that it forwards.
   An HTTP-to-HTTP gateway &MUST; send an appropriate Via header field in
   each inbound request message and &MAY; send a Via header field in
   forwarded response messages.
</t>
<t>
   For each intermediary, the received-protocol indicates the protocol and
   protocol version used by the upstream sender of the message. Hence, the
   Via field value records the advertised protocol capabilities of the
   request/response chain such that they remain visible to downstream
   recipients; this can be useful for determining what backwards-incompatible
   features might be safe to use in response, or within a later request, as
   described in <xref target="protocol.version"/>. For brevity, the protocol-name
   is omitted when the received protocol is HTTP.
</t>
<t>
   The received-by portion of the field value is normally the host and optional
   port number of a recipient server or client that subsequently forwarded the
   message.
   However, if the real host is considered to be sensitive information, a
   sender &MAY; replace it with a pseudonym. If a port is not provided,
   a recipient &MAY; interpret that as meaning it was received on the default
   TCP port, if any, for the received-protocol.
</t>
<t>
   A sender &MAY; generate comments in the Via header field to identify the
   software of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
   <x:ref>Server</x:ref> header fields. However, all comments in the Via field
   are optional, and a recipient &MAY; remove them prior to forwarding the
   message.
</t>
<t>
   For example, a request message could be sent from an HTTP/1.0 user
   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
   forward the request to a public proxy at p.example.net, which completes
   the request by forwarding it to the origin server at www.example.com.
   The request received by www.example.com would then have the following
   Via header field:
</t>
<figure><artwork type="example">
  Via: 1.0 fred, 1.1 p.example.net
</artwork></figure>
<t>
   An intermediary used as a portal through a network firewall
   &SHOULD-NOT; forward the names and ports of hosts within the firewall
   region unless it is explicitly enabled to do so. If not enabled, such an
   intermediary &SHOULD; replace each received-by host of any host behind the
   firewall by an appropriate pseudonym for that host.
</t>
<t>
   An intermediary &MAY; combine an ordered subsequence of Via header
   field entries into a single such entry if the entries have identical
   received-protocol values. For example,
</t>
<figure><artwork type="example">
  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
</artwork></figure>
<t>
  could be collapsed to
</t>
<figure><artwork type="example">
  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
</artwork></figure>
<t>
   A sender &SHOULD-NOT; combine multiple entries unless they are all
   under the same organizational control and the hosts have already been
   replaced by pseudonyms. A sender &MUST-NOT; combine entries that
   have different received-protocol values.
</t>
</section>

<section title="Transformations" anchor="message.transformations">
   <iref primary="true" item="transforming proxy"/>
   <iref primary="true" item="non-transforming proxy"/>
<t>
   Some intermediaries include features for transforming messages and their
   payloads. 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
   link. However, operational problems might occur when these transformations
   are applied to payloads intended for critical applications, such as medical
   imaging or scientific data analysis, particularly when integrity checks or
   digital signatures are used to ensure that the payload received is
   identical to the original.
</t>
<t>
   An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>"
   if it is designed or configured to modify messages in a semantically
   meaningful way (i.e., modifications, beyond those required by normal
   HTTP processing, that change the message in a way that would be
   significant to the original sender or potentially significant to
   downstream recipients).  For example, a transforming proxy might be
   acting as a shared annotation server (modifying responses to include
   references to a local annotation database), a malware filter, a
   format transcoder, or a privacy filter. Such transformations are presumed
   to be desired by whichever client (or client organization) selected the
   proxy.
</t>
<t>
   If a proxy receives a request-target with a host name that is not a
   fully qualified domain name, it &MAY; add its own domain to the host name
   it received when forwarding the request.  A proxy &MUST-NOT; change the
   host name if the request-target contains a fully qualified domain name.
</t>
<t>
   A proxy &MUST-NOT; modify the "absolute-path" and "query" parts of the
   received request-target when forwarding it to the next inbound server,
   except as noted above to replace an empty path with "/" or "*".
</t>
<t>
   A proxy &MAY; modify the message body through application
   or removal of a transfer coding (<xref target="transfer.codings"/>).
</t>
<t>
   A proxy &MUST-NOT; transform the payload (<xref target="payload"/>) of a message that
   contains a no-transform cache-control directive (<xref target="header.cache-control"/>).
</t>
<t>
   A proxy &MAY; transform the payload of a message
   that does not contain a no-transform cache-control directive.
   A proxy that transforms a payload &MUST; add a <x:ref>Warning</x:ref>
   header field with the warn-code of 214 ("Transformation Applied")
   if one is not already in the message (see <xref target="header.warning"/>).
   A proxy that transforms the payload of a <x:ref>200 (OK)</x:ref> response
   can further inform downstream recipients that a transformation has been
   applied by changing the response status code to
   <x:ref>203 (Non-Authoritative Information)</x:ref> (<xref target="status.203"/>).
</t>
<t>
   A proxy &SHOULD-NOT; modify header fields that provide information about
   the endpoints of the communication chain, the resource state, or the
   selected representation (other than the payload) unless the field's
   definition specifically allows such modification or the modification is
   deemed necessary for privacy or security.
</t>
</section>
</section>
</section>

<section title="Representations" anchor="representations">
   <iref primary="true" item="representation"/>
   <iref primary="true" item="selected representation"/>
   <x:anchor-alias value="representation"/>
   <x:anchor-alias value="selected representation"/>
<t>
   Considering that a resource could be anything, and that the uniform
   interface provided by HTTP is similar to a window through which one can
   observe and act upon such a thing only through the communication of
   messages to some independent actor on the other side, an abstraction is
   needed to represent ("take the place of") the current or desired state of
   that thing in our communications. That abstraction is called a
   representation <xref target="REST"/>.
</t>
<t>
   For the purposes of HTTP, a "<x:dfn>representation</x:dfn>" is information
   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,
   and that consists of a set of representation metadata and a potentially
   unbounded stream of representation data.
</t>
<t>
   An origin server might be provided with, or be capable of generating, multiple
   representations that are each intended to reflect the current state of a
   <x:ref>target resource</x:ref>. In such cases, some algorithm is used by
   the origin server to select one of those representations as most applicable
   to a given request, usually based on <x:ref>content negotiation</x:ref>.
   This "<x:dfn>selected representation</x:dfn>" is used to provide the data
   and metadata for evaluating conditional requests <xref target="preconditions"/> and
   constructing the payload for <x:ref>200 (OK)</x:ref> and
   <x:ref>304 (Not Modified)</x:ref> responses to GET (<xref target="GET"/>).
</t>

<section title="Representation Data" anchor="representation.data">
  <x:anchor-alias value="representation-data"/>
<t>
   The representation data associated with an HTTP message is
   either provided as the payload body of the message or
   referred to by the message semantics and the effective request
   URI.  The representation data is in a format and encoding defined by
   the representation metadata header fields.
</t>
<t>
   The data type of the representation data is determined via the header fields
   <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
   These define a two-layer, ordered encoding model:
</t>
<figure><artwork type="example">
  representation-data := Content-Encoding( Content-Type( bits ) )
</artwork></figure>

<section title="Media Type" anchor="media.type">
  <x:anchor-alias value="media-type"/>
  <x:anchor-alias value="type"/>
  <x:anchor-alias value="subtype"/>
<t>
   HTTP uses media types <xref target="RFC2046"/> in the
   <x:ref>Content-Type</x:ref> (<xref target="header.content-type"/>)
   and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in
   order to provide open and extensible data typing and type negotiation.
   Media types define both a data format and various processing models:
   how to process that data in accordance with each context in which it
   is received.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
  <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
  <x:ref>type</x:ref>       = <x:ref>token</x:ref>
  <x:ref>subtype</x:ref>    = <x:ref>token</x:ref>
</artwork></figure>
<t anchor="rule.parameter">
  <x:anchor-alias value="parameter"/>
   The type/subtype &MAY; be followed by parameters in the form of
   name=value pairs.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/>
  <x:ref>parameter</x:ref>      = <x:ref>token</x:ref> "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> )
</artwork></figure>
<t>
   The type, subtype, and parameter name tokens are case-insensitive.
   Parameter values might or might not be case-sensitive, depending on the
   semantics of the parameter name.  The presence or absence of a parameter might
   be significant to the processing of a media-type, depending on its
   definition within the media type registry.
</t>
<t>
   A parameter value that matches the <x:ref>token</x:ref> production can be
   transmitted either as a token or within a quoted-string. The quoted and
   unquoted values are equivalent. For example, the following examples are
   all equivalent, but the first is preferred for consistency:
</t>
<figure><artwork type="example">
  text/html;charset=utf-8
  text/html;charset=UTF-8
  Text/HTML;Charset="utf-8"
  text/html; charset="utf-8"
</artwork></figure>
<t>
   Media types ought to be registered with IANA according to the
   procedures defined in <xref target="BCP13"/>.
</t>
<aside>
  <t>
    &Note; Unlike some similar constructs in other header fields, media type
    parameters do not allow whitespace (even "bad" whitespace) around the "="
    character.
  </t>
</aside>

<section title="Charset" anchor="charset">
  <x:anchor-alias value="rule.charset"/>
<t>
   HTTP uses <x:dfn>charset</x:dfn> names to indicate or negotiate the
   character encoding scheme of a textual representation
   <xref target="RFC6365"/>.
   A charset is identified by a case-insensitive token.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
  <x:ref>charset</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t>
   Charset names ought to be registered in the IANA "Character Sets" registry
   (<eref target="https://www.iana.org/assignments/character-sets"/>)
   according to the procedures defined in <xref target="RFC2978"/>.
</t>
</section>

<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
<t>
   Media types are registered with a canonical form in order to be
   interoperable among systems with varying native encoding formats.
   Representations selected or transferred via HTTP ought to be in canonical
   form, for many of the same reasons described by the Multipurpose Internet
   Mail Extensions (MIME) <xref target="RFC2045"/>.
   However, the performance characteristics of email deployments (i.e., store
   and forward messages to peers) are significantly different from those
   common to HTTP and the Web (server-based information services).
   Furthermore, MIME's constraints for the sake of compatibility with older
   mail transfer protocols do not apply to HTTP
   (see <xref target="differences.between.http.and.mime"/>).
</t>
<t>
   MIME's canonical form requires that media subtypes of the "text"
   type use CRLF as the text line break. HTTP allows the
   transfer of text media with plain CR or LF alone representing a line
   break, when such line breaks are consistent for an entire representation.
   An HTTP sender &MAY; generate, and a recipient &MUST; be able to parse,
   line breaks in text media that consist of CRLF, bare CR, or bare LF.
   In addition, text media in HTTP is not limited to charsets that
   use octets 13 and 10 for CR and LF, respectively.
   This flexibility regarding line breaks applies only to text within a
   representation that has been assigned a "text" media type; it does not
   apply to "multipart" types or HTTP elements outside the payload body
   (e.g., header fields).
</t>
<t>
   If a representation is encoded with a content-coding, the underlying
   data ought to be in a form defined above prior to being encoded.
</t>
</section>

<section title="Multipart Types" anchor="multipart.types">
<t>
   MIME provides for a number of "multipart" types &mdash; encapsulations of
   one or more representations within a single message body. All multipart
   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
   and include a boundary parameter as part of the media type
   value. The message body is itself a protocol element; a sender &MUST;
   generate only CRLF to represent line breaks between body parts.
</t>
<t>
   HTTP message framing does not use the multipart boundary as an indicator
   of message body length, though it might be used by implementations that
   generate or process the payload. For example, the "multipart/form-data"
   type is often used for carrying form data in a request, as described in
   <xref target="RFC2388"/>, and the "multipart/byteranges" type is defined
   by this specification for use in some <x:ref>206 (Partial Content)</x:ref>
   responses <xref target="status.206"/>.
</t>
</section>
</section>

<section title="Content Codings" anchor="content.codings">
  <iref primary="true" item="content coding"/>
  <iref primary="true" item="compress (content coding)"/>
  <iref primary="true" item="x-compress (content coding)"/>
  <iref primary="true" item="deflate (content coding)"/>
  <iref primary="true" item="gzip (content coding)"/>
  <iref primary="true" item="x-gzip (content coding)"/>
  <x:anchor-alias value="content-coding"/>
<t>
   Content coding values indicate an encoding transformation that has
   been or can be applied to a representation. Content codings are primarily
   used to allow a representation to be compressed or otherwise usefully
   transformed without losing the identity of its underlying media type
   and without loss of information. Frequently, the representation is stored
   in coded form, transmitted directly, and only decoded by the final recipient.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
  <x:ref>content-coding</x:ref>   = <x:ref>token</x:ref>
</artwork></figure>
<t>
   Content-coding values are used in the
   <x:ref>Accept-Encoding</x:ref> (<xref target="header.accept-encoding"/>)
   and <x:ref>Content-Encoding</x:ref> (<xref target="header.content-encoding"/>)
   header fields.
</t>
<t>
  The following content-coding values are defined by this specification:
</t>
<texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table">
   <ttcol>Name</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Reference</ttcol>
   <c>compress</c>
   <c>UNIX "compress" data format <xref target="Welch"/></c>
   <c>
      <xref target="compress.coding"/>
   </c>
   <c>deflate</c>
   <c>"deflate" compressed data (<xref target="RFC1951"/>) inside
   the "zlib" data format (<xref target="RFC1950"/>)</c>
   <c>
      <xref target="deflate.coding"/>
   </c>
   <c>gzip</c>
   <c>GZIP file format <xref target="RFC1952"/></c>
   <c>
      <xref target="gzip.coding"/>
   </c>
   <c>identity</c>
   <c>Reserved
      (synonym for "no encoding" in <x:ref>Accept-Encoding</x:ref>)</c>
   <c>
      <xref target="header.accept-encoding"/>
   </c>
   <c>x-compress</c>
   <c>Deprecated (alias for compress)</c>
   <c>
      <xref target="compress.coding"/>
   </c>
   <c>x-gzip</c>
   <c>Deprecated (alias for gzip)</c>
   <c>
      <xref target="gzip.coding"/>
   </c>
</texttable>

<section title="Compress Coding" anchor="compress.coding">
<iref item="compress (Coding Format)"/>
<t>
   The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
   <xref target="Welch"/> that is commonly produced by the UNIX file
   compression program "compress".
   A recipient &SHOULD; consider "x-compress" to be equivalent to "compress".
</t>
</section>

<section title="Deflate Coding" anchor="deflate.coding">
<iref item="deflate (Coding Format)"/>
<t>
   The "deflate" coding is a "zlib" data format <xref target="RFC1950"/>
   containing a "deflate" compressed data stream <xref target="RFC1951"/>
   that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and
   Huffman coding.
</t>
<aside>
  <t>
    &Note; Some non-conformant implementations send the "deflate"
    compressed data without the zlib wrapper.
   </t>
</aside>
</section>

<section title="Gzip Coding" anchor="gzip.coding">
<iref item="gzip (Coding Format)"/>
<t>
   The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check
   (CRC) that is commonly
   produced by the gzip file compression program <xref target="RFC1952"/>.
   A recipient &SHOULD; consider "x-gzip" to be equivalent to "gzip".
</t>
</section>

<section title="Content Coding Extensibility" anchor="content.coding.extensibility">
<t>
   Additional content codings, outside the scope of this specification, have
   been specified for use in HTTP. All such content codings ought to be
   registered within the "HTTP Content Coding Registry".
</t>

<section title="Content Coding Registry" anchor="content.coding.registry">
<t>
   The "HTTP Content Coding Registry", maintained by
   IANA at <eref target="https://www.iana.org/assignments/http-parameters/"/>,
   registers <x:ref>content-coding</x:ref> names.
</t>
<t>
   Content coding registrations &MUST; include the following fields:
   <list style="symbols">
     <t>Name</t>
     <t>Description</t>
     <t>Pointer to specification text</t>
   </list>
</t>
<t>
   Names of content codings &MUST-NOT; overlap with names of transfer codings
   (<xref target="transfer.codings"/>), unless the encoding transformation is identical (as
   is the case for the compression codings defined in
   <xref target="content.codings"/>).
</t>
<t>
   Values to be added to this namespace require IETF Review
   (see <xref target="RFC8126" x:fmt="of" x:sec="4.8"/>) and &MUST;
   conform to the purpose of content coding defined in
   <xref target="content.codings"/>.
</t>
</section>
</section>
</section>

<section title="Language Tags" anchor="language.tags">
  <x:anchor-alias value="language-tag"/>
<t>
   A language tag, as defined in <xref target="RFC5646"/>, identifies a
   natural language spoken, written, or otherwise conveyed by human beings for
   communication of information to other human beings. Computer languages are
   explicitly excluded.
</t>
<t>
   HTTP uses language tags within the <x:ref>Accept-Language</x:ref> and
   <x:ref>Content-Language</x:ref> header fields.
   <x:ref>Accept-Language</x:ref> uses the broader language-range production
   defined in <xref target="header.accept-language"/>, whereas
   <x:ref>Content-Language</x:ref> uses the language-tag production defined
   below.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>
  <x:ref>language-tag</x:ref> = &lt;Language-Tag, see <xref target="RFC5646" x:sec="2.1"/>&gt;
</artwork></figure>
<t>
   A language tag is a sequence of one or more case-insensitive subtags, each
   separated by a hyphen character ("-", %x2D).  In most cases, a language tag
   consists of a primary language subtag that identifies a broad family of
   related languages (e.g., "en" = English), which is optionally followed by a
   series of subtags that refine or narrow that language's range (e.g.,
   "en-CA" = the variety of English as communicated in Canada).
   Whitespace is not allowed within a language tag.
   Example tags include:
</t>
<figure><artwork type="example">
  fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
</artwork></figure>
<t>
   See <xref target="RFC5646"/> for further information. 
</t>
</section>

<section title="Range Units" anchor="range.units">
  <x:anchor-alias value="range-unit"/>
  <x:anchor-alias value="range unit"/>
<t>
   A representation can be partitioned into subranges according to various
   structural units, depending on the structure inherent in the
   representation's media type. This "<x:dfn>range unit</x:dfn>" is used
   in the <x:ref>Accept-Ranges</x:ref> (<xref target="header.accept-ranges"/>)
   response header field to advertise support for range requests, the
   <x:ref>Range</x:ref> (<xref target="header.range"/>) request header field
   to delineate the parts of a representation that are requested, and the
   <x:ref>Content-Range</x:ref> (<xref target="header.content-range"/>)
   payload header field to describe which part of a representation is being
   transferred.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref item="Grammar" subitem="bytes-unit"/><iref item="Grammar" subitem="other-range-unit"/>
  <x:ref>range-unit</x:ref>       = <x:ref>bytes-unit</x:ref> / <x:ref>other-range-unit</x:ref>
</artwork></figure>
<t>
  The following range unit names are defined by this document:
</t>
<texttable align="left" suppress-title="true" anchor="iana.range.units.table">
   <ttcol>Range Unit Name</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Reference</ttcol>

   <c>bytes</c>
   <c>a range of octets</c>
   <c><xref target="byte.ranges"/></c>

   <c>none</c>
   <c>reserved as keyword, indicating no ranges are supported</c>
   <c><xref target="header.accept-ranges"/></c>
</texttable>

<section title="Byte Ranges" anchor="byte.ranges">
  <x:anchor-alias value="bytes-unit"/>
<t>
   Since representation data is transferred in payloads as a sequence of
   octets, a byte range is a meaningful substructure for any representation
   transferable over HTTP (<xref target="representations"/>). The "bytes" range unit is
   defined for expressing subranges of the data's octet sequence.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="bytes-unit"/>
  <x:ref>bytes-unit</x:ref>       = "bytes"
</artwork></figure>
<t anchor="rule.ranges-specifier">
  <x:anchor-alias value="byte-range-set"/>
  <x:anchor-alias value="byte-range-spec"/>
  <x:anchor-alias value="byte-ranges-specifier"/>
  <x:anchor-alias value="first-byte-pos"/>
  <x:anchor-alias value="last-byte-pos"/>
  <x:anchor-alias value="ranges-specifier"/>
  <x:anchor-alias value="suffix-byte-range-spec"/>
  <x:anchor-alias value="suffix-length"/>
   A byte-range request can specify a single range of bytes or a set
   of ranges within a single representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-range-set"/><iref primary="true" item="Grammar" subitem="byte-range-spec"/><iref primary="true" item="Grammar" subitem="first-byte-pos"/><iref primary="true" item="Grammar" subitem="last-byte-pos"/>
  <x:ref>byte-ranges-specifier</x:ref> = <x:ref>bytes-unit</x:ref> "=" <x:ref>byte-range-set</x:ref>
  <x:ref>byte-range-set</x:ref>  = 1#( <x:ref>byte-range-spec</x:ref> / <x:ref>suffix-byte-range-spec</x:ref> )
  <x:ref>byte-range-spec</x:ref> = <x:ref>first-byte-pos</x:ref> "-" [ <x:ref>last-byte-pos</x:ref> ]
  <x:ref>first-byte-pos</x:ref>  = 1*<x:ref>DIGIT</x:ref>
  <x:ref>last-byte-pos</x:ref>   = 1*<x:ref>DIGIT</x:ref>
</artwork></figure>
<t>
   The <x:ref>first-byte-pos</x:ref> value in a <x:ref>byte-range-spec</x:ref>
   gives the byte-offset of the first byte in a range.
   The <x:ref>last-byte-pos</x:ref> value gives the byte-offset of the last
   byte in the range; that is, the byte positions specified are inclusive.
   Byte offsets start at zero.
</t>
<t>
   Examples of <x:ref>byte-ranges-specifier</x:ref> values:
  <list style="symbols">
     <t>The first 500 bytes (byte offsets 0-499, inclusive):
<figure><artwork type="example" x:indent-with="   ">
  bytes=0-499
</artwork></figure>
    </t>
     <t>The second 500 bytes (byte offsets 500-999, inclusive):
<figure><artwork type="example" x:indent-with="   ">
  bytes=500-999
</artwork></figure>
    </t>
  </list>
</t>
<t>
   A <x:ref>byte-range-spec</x:ref> is invalid if the
   <x:ref>last-byte-pos</x:ref> value is present and less than the
   <x:ref>first-byte-pos</x:ref>.
</t>
<t>
   A client can limit the number of bytes requested without knowing the size
   of the selected representation.
   If the <x:ref>last-byte-pos</x:ref> value is absent, or if the value is
   greater than or equal to the current length of the representation data, the
   byte range is interpreted as the remainder of the representation (i.e., the
   server replaces the value of <x:ref>last-byte-pos</x:ref> with a value that
   is one less than the current length of the selected representation).
</t>
<t>
   A client can request the last N bytes of the selected representation using
   a <x:ref>suffix-byte-range-spec</x:ref>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
  <x:ref>suffix-byte-range-spec</x:ref> = "-" <x:ref>suffix-length</x:ref>
  <x:ref>suffix-length</x:ref> = 1*<x:ref>DIGIT</x:ref>
</artwork></figure>
<t>
   If the selected representation is shorter than the specified
   <x:ref>suffix-length</x:ref>, the entire representation is used.
</t>
<t>
   Additional examples, assuming a representation of length 10000:
  <list style="symbols">
     <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
<figure><artwork type="example" x:indent-with="   ">
  bytes=-500
</artwork></figure>
    Or:
<figure><artwork type="example" x:indent-with="   ">
  bytes=9500-
</artwork></figure>
    </t>
     <t>The first and last bytes only (bytes 0 and 9999):
<figure><artwork type="example" x:indent-with="   ">
  bytes=0-0,-1
</artwork></figure>
     </t>
     <t>Other valid (but not canonical) specifications of the second 500
        bytes (byte offsets 500-999, inclusive):
<figure><artwork type="example" x:indent-with="   ">
  bytes=500-600,601-999
  bytes=500-700,601-999
</artwork></figure>
     </t>
  </list>
</t>
<t>
   If a valid <x:ref>byte-range-set</x:ref> includes at least one
   <x:ref>byte-range-spec</x:ref> with a <x:ref>first-byte-pos</x:ref> that is
   less than the current length of the representation, or at least one
   <x:ref>suffix-byte-range-spec</x:ref> with a non-zero
   <x:ref>suffix-length</x:ref>, then the <x:ref>byte-range-set</x:ref> is
   satisfiable. Otherwise, the <x:ref>byte-range-set</x:ref> is unsatisfiable.
</t>
<t>
   In the byte-range syntax, <x:ref>first-byte-pos</x:ref>,
   <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are
   expressed as decimal number of octets. Since there is no predefined limit
   to the length of a payload, recipients &MUST; anticipate potentially
   large decimal numerals and prevent parsing errors due to integer conversion
   overflows.
</t>
</section>

<section title="Other Range Units" anchor="range.units.other">
  <x:anchor-alias value="other-range-unit"/>
<t>
  Range units are intended to be extensible.  New range units ought to be
  registered with IANA, as defined in <xref target="range.unit.registry"/>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="other-range-unit"/>
  <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
</section>

<section title="Range Unit Registry" anchor="range.unit.registry">
<t>
   The "HTTP Range Unit Registry" defines the namespace for the range
   unit names and refers to their corresponding specifications.
   It is maintained at
   <eref target="https://www.iana.org/assignments/http-parameters"/>.
</t>
<t>
   Registration of an HTTP Range Unit &MUST; include the following fields:
   <list style="symbols">
     <t>Name</t>
     <t>Description</t>
     <t>Pointer to specification text</t>
   </list>
</t>
<t>
  Values to be added to this namespace require IETF Review
  (see <xref target="RFC8126" x:fmt="," x:sec="4.8"/>).
</t>
</section>
</section>
</section>

<section title="Representation Metadata" anchor="representation.metadata">
  <x:anchor-alias value="representation-header"/>
<t>
   Representation header fields provide metadata about the representation.
   When a message includes a payload body, the representation header fields
   describe how to interpret the representation data enclosed in the payload
   body.  In a response to a HEAD request, the representation header fields
   describe the representation data that would have been enclosed in the
   payload body if the same request had been a GET.
</t>
<t>
   The following header fields convey representation metadata:
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
  <c>Content-Length</c> <c><xref target="header.content-length"/></c>
  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
</texttable>

<section title="Content-Type" anchor="header.content-type">
  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Type"/>
<t>
   The "Content-Type" header field indicates the media type of the
   associated representation: either the representation enclosed in
   the message payload or the <x:ref>selected representation</x:ref>, as determined by the
   message semantics.  The indicated media type defines both the data format
   and how that data is intended to be processed by a recipient, within the
   scope of the received message semantics, after any content codings
   indicated by <x:ref>Content-Encoding</x:ref> are decoded.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
</artwork></figure>
<t>
   Media types are defined in <xref target="media.type"/>. An example of the
   field is
</t>
<figure><artwork type="example">
  Content-Type: text/html; charset=ISO-8859-4
</artwork></figure>
<t>
   A sender that generates a message containing a payload body &SHOULD;
   generate a Content-Type header field in that message unless the intended
   media type of the enclosed representation is unknown to the sender.
   If a Content-Type header field is not present, the recipient &MAY; either
   assume a media type of
   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
   or examine the data to determine its type.
</t>
<t>
   In practice, resource owners do not always properly configure their origin
   server to provide the correct Content-Type for a given representation,
   with the result that some clients will examine a payload's content
   and override the specified type.
   Clients that do so risk drawing incorrect conclusions, which might expose
   additional security risks (e.g., "privilege escalation").  Furthermore,
   it is impossible to determine the sender's intent by examining the data
   format: many data formats match multiple media types that differ only in
   processing semantics.  Implementers are encouraged to provide a means of
   disabling such "content sniffing" when it is used.
</t>
</section>

<section title="Content-Encoding" anchor="header.content-encoding">
  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Encoding"/>
<t>
   The "Content-Encoding" header field indicates what content codings 
   have been applied to the representation, beyond those inherent in the media
   type, and thus what decoding mechanisms have to be applied in order to
   obtain data in the media type referenced by the <x:ref>Content-Type</x:ref>
   header field.
   Content-Encoding is primarily used to allow a representation's data to be
   compressed without losing the identity of its underlying media type.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
</artwork></figure>
<t>
   An example of its use is
</t>
<figure><artwork type="example">
  Content-Encoding: gzip
</artwork></figure>
<t>
   If one or more encodings have been applied to a representation, the sender
   that applied the encodings &MUST; generate a Content-Encoding header field
   that lists the content codings in the order in which they were applied.
   Additional information about the encoding parameters can be provided
   by other header fields not defined by this specification.
</t>
<t>
   Unlike Transfer-Encoding (<xref target="header.transfer-encoding"/>), the codings listed
   in Content-Encoding are a characteristic of the representation; the
   representation is defined in terms of the coded form, and all other
   metadata about the representation is about the coded form unless otherwise
   noted in the metadata definition. Typically, the representation is only
   decoded just prior to rendering or analogous usage.
</t>
<t>
   If the media type includes an inherent encoding, such as a data format
   that is always compressed, then that encoding would not be restated in 
   Content-Encoding even if it happens to be the same algorithm as one
   of the content codings.  Such a content coding would only be listed if,
   for some bizarre reason, it is applied a second time to form the
   representation.  Likewise, an origin server might choose to publish the
   same data as multiple representations that differ only in whether
   the coding is defined as part of <x:ref>Content-Type</x:ref> or
   Content-Encoding, since some user agents will behave differently in their
   handling of each response (e.g., open a "Save as ..." dialog instead of
   automatic decompression and rendering of content).
</t>
<t>
   An origin server &MAY; respond with a status code of
   <x:ref>415 (Unsupported Media Type)</x:ref> if a representation in the
   request message has a content coding that is not acceptable.
</t>
</section>

<section title="Content-Language" anchor="header.content-language">
  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Language"/>
<t>
   The "Content-Language" header field describes the natural
   language(s) of the intended audience for the representation. Note that this might
   not be equivalent to all the languages used within the representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
</artwork></figure>
<t>
   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
   Content-Language is to allow a user to identify and differentiate
   representations according to the users' own preferred language. Thus, if the
   content is intended only for a Danish-literate audience, the
   appropriate field is
</t>
<figure><artwork type="example">
  Content-Language: da
</artwork></figure>
<t>
   If no Content-Language is specified, the default is that the content
   is intended for all language audiences. This might mean that the
   sender does not consider it to be specific to any natural language,
   or that the sender does not know for which language it is intended.
</t>
<t>
   Multiple languages &MAY; be listed for content that is intended for
   multiple audiences. For example, a rendition of the "Treaty of
   Waitangi", presented simultaneously in the original Maori and English
   versions, would call for
</t>
<figure><artwork type="example">
  Content-Language: mi, en
</artwork></figure>
<t>
   However, just because multiple languages are present within a representation
   does not mean that it is intended for multiple linguistic audiences.
   An example would be a beginner's language primer, such as "A First
   Lesson in Latin", which is clearly intended to be used by an
   English-literate audience. In this case, the Content-Language would
   properly only include "en".
</t>
<t>
   Content-Language &MAY; be applied to any media type &mdash; it is not
   limited to textual documents.
</t>
</section>

<section title="Content-Length" anchor="header.content-length">
  <iref primary="true" item="Content-Length header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Length"/>
<t><cref>
   The "Content-Length" header field indicates the number of data octets
   (body length) for the representation. In some cases, Content-Length is
   used to define or estimate message framing.
</cref></t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
  <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>
</artwork></figure>
<t>
   An example is
</t>
<figure><artwork type="example">
  Content-Length: 3495
</artwork></figure>
<t>
   A sender &MUST-NOT; send a Content-Length header field in any message that
   contains a <x:ref>Transfer-Encoding</x:ref> header field.
</t>
<t>
   A user agent &SHOULD; send a Content-Length in a request message when no
   <x:ref>Transfer-Encoding</x:ref> is sent and the request method defines
   a meaning for an enclosed payload body. For example, a Content-Length
   header field is normally sent in a POST request even when the value is
   0 (indicating an empty payload body).  A user agent &SHOULD-NOT; send a
   Content-Length header field when the request message does not contain a
   payload body and the method semantics do not anticipate such a body.
</t>
<t>
   A server &MAY; send a Content-Length header field in a response to a HEAD
   request (<xref target="HEAD"/>); a server &MUST-NOT; send Content-Length in such a
   response unless its field-value equals the decimal number of octets that
   would have been sent in the payload body of a response if the same
   request had used the GET method.
</t>
<t>
   A server &MAY; send a Content-Length header field in a
   <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request
   (<xref target="status.304"/>); a server &MUST-NOT; send Content-Length in such a
   response unless its field-value equals the decimal number of octets that
   would have been sent in the payload body of a <x:ref>200 (OK)</x:ref>
   response to the same request.
</t>
<t>
   A server &MUST-NOT; send a Content-Length header field in any response
   with a status code of
   <x:ref>1xx (Informational)</x:ref> or <x:ref>204 (No Content)</x:ref>.
   A server &MUST-NOT; send a Content-Length header field in any
   <x:ref>2xx (Successful)</x:ref> response to a CONNECT request (<xref target="CONNECT"/>).
</t>
<t>
   Aside from the cases defined above, in the absence of Transfer-Encoding,
   an origin server &SHOULD; send a Content-Length header field when the
   payload body size is known prior to sending the complete header section.
   This will allow downstream recipients to measure transfer progress,
   know when a received message is complete, and potentially reuse the
   connection for additional requests.
</t>
<t>
   Any Content-Length field value greater than or equal to zero is valid.
   Since there is no predefined limit to the length of a payload, a
   recipient &MUST; anticipate potentially large decimal numerals and
   prevent parsing errors due to integer conversion overflows
   (<xref target="attack.protocol.element.length"/>).
</t>
<t>
   If a message is received that has multiple Content-Length header fields
   with field-values consisting of the same decimal value, or a single
   Content-Length header field with a field value containing a list of
   identical decimal values (e.g., "Content-Length: 42, 42"), indicating that
   duplicate Content-Length header fields have been generated or combined by an
   upstream message processor, then the recipient &MUST; either reject the
   message as invalid or replace the duplicated field-values with a single
   valid Content-Length field containing that decimal value prior to
   determining the message body length or forwarding the message.
</t>
</section>

<section title="Content-Location" anchor="header.content-location">
  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Location"/>
<t>
   The "Content-Location" header field references a URI that can be used
   as an identifier for a specific resource corresponding to the
   representation in this message's payload.
   In other words, if one were to perform a GET request on this URI at the time
   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
   contain the same representation that is enclosed as payload in this message.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
</artwork></figure>
<t>
   The Content-Location value is not a replacement for the effective
   Request URI (<xref target="effective.request.uri"/>).  It is representation metadata.
   It has the same syntax and semantics as the header field of the same name
   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
   However, its appearance in an HTTP message has some special implications
   for HTTP recipients.
</t>
<t>
   If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
   response message and its value refers (after conversion to absolute form)
   to a URI that is the same as the effective request URI, then
   the recipient &MAY; consider the payload to be a current representation of
   that resource at the time indicated by the message origination date.
   For a GET (<xref target="GET"/>) or HEAD (<xref target="HEAD"/>) request,
   this is the same as the default semantics when no Content-Location is
   provided by the server.
   For a state-changing request like PUT (<xref target="PUT"/>) or
   POST (<xref target="POST"/>), it implies that the server's response
   contains the new representation of that resource, thereby distinguishing it
   from representations that might only report about the action
   (e.g., "It worked!").
   This allows authoring applications to update their local copies without
   the need for a subsequent GET request.
</t>
<t>
   If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
   response message and its field-value refers to a URI that differs from the
   effective request URI, then the origin server claims that the URI
   is an identifier for a different resource corresponding to the enclosed
   representation. Such a claim can only be trusted if both identifiers share
   the same resource owner, which cannot be programmatically determined via
   HTTP.
   <list style="symbols">
    <t>For a response to a GET or HEAD request, this is an indication that the
       effective request URI refers to a resource that is subject to content
       negotiation and the Content-Location field-value is a more specific
       identifier for the <x:ref>selected representation</x:ref>.</t>
    <t>For a <x:ref>201 (Created)</x:ref> response to a state-changing method,
       a Content-Location field-value that is identical to the
       <x:ref>Location</x:ref> field-value indicates that this payload is a
       current representation of the newly created resource.</t>
    <t>Otherwise, such a Content-Location indicates that this payload is a
       representation reporting on the requested action's status and that the
       same report is available (for future access with GET) at the given URI.
       For example, a purchase transaction made via a POST request might
       include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
       response; the Content-Location field-value provides an identifier for
       retrieving a copy of that same receipt in the future.</t>
   </list>
</t>
<t>
   A user agent that sends Content-Location in a request message is stating
   that its value refers to where the user agent originally obtained the
   content of the enclosed representation (prior to any modifications made by
   that user agent).  In other words, the user agent is providing a back link
   to the source of the original representation.
</t>
<t>
   An origin server that receives a Content-Location field in a request
   message &MUST; treat the information as transitory request context rather
   than as metadata to be saved verbatim as part of the representation.
   An origin server &MAY; use that context to guide in processing the
   request or to save it for other uses, such as within source links or
   versioning metadata. However, an origin server &MUST-NOT; use such context
   information to alter the request semantics.
</t>
<t>
   For example, if a client makes a PUT request on a negotiated resource and
   the origin server accepts that PUT (without redirection), then the new
   state of that resource is expected to be consistent with the one
   representation supplied in that PUT; the Content-Location cannot be used as
   a form of reverse content selection identifier to update only one of the
   negotiated representations. If the user agent had wanted the latter
   semantics, it would have applied the PUT directly to the Content-Location
   URI.
</t>
</section>
</section>

<section title="Payload" anchor="payload">
<iref item="payload"/>
<t>
   Some HTTP messages transfer a complete or partial representation as the
   message "<x:dfn>payload</x:dfn>".  In some cases, a payload might contain
   only the associated representation's header fields (e.g., responses to
   HEAD) or only some part(s) of the representation data
   (e.g., the <x:ref>206 (Partial Content)</x:ref> status code).
</t>
<t>
   Header fields that specifically describe the payload, rather than the
   associated representation, are referred to as "payload header fields".
   Payload header fields are defined in other parts of this specification,
   due to their impact on message parsing.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>Content-Range</c> <c><xref target="header.content-range"/></c>
  <c>Trailer</c> <c><xref target="header.trailer"/></c>
  <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
</texttable>

<section title="Purpose" anchor="payload.purpose">
<t>
   The purpose of a payload in a request is defined by the method semantics.
   For example, a representation in the payload of a PUT request
   (<xref target="PUT"/>) represents the desired state of the
   <x:ref>target resource</x:ref> if the request is successfully applied,
   whereas a representation in the payload of a POST request
   (<xref target="POST"/>) represents information to be processed by the
   target resource.
</t>
<t>
   In a response, the payload's purpose is defined by both the request method
   and the response status code.
   For example, the payload of a <x:ref>200 (OK)</x:ref> response to GET
   (<xref target="GET"/>) represents the current state of the
   <x:ref>target resource</x:ref>, as observed at the time of the message
   origination date (<xref target="header.date"/>), whereas the payload of
   the same status code in a response to POST might represent either the
   processing result or the new state of the target resource after applying
   the processing. Response messages with an error status code usually contain
   a payload that represents the error condition, such that it describes the
   error state and what next steps are suggested for resolving it.
</t>
</section>

<section title="Identification" anchor="identifying.payload">
<t>
   When a complete or partial representation is transferred in a message
   payload, it is often desirable for the sender to supply, or the recipient
   to determine, an identifier for a resource corresponding to that
   representation.
</t>
<t>
   For a request message:
   <list style="symbols">
      <t>If the request has a <x:ref>Content-Location</x:ref> header field,
         then the sender asserts that the payload is a representation of the
         resource identified by the Content-Location field-value. However,
         such an assertion cannot be trusted unless it can be verified by
         other means (not defined by this specification). The information
         might still be useful for revision history links.</t>
      <t>Otherwise, the payload is unidentified.</t>
   </list>
</t>
<t>
   For a response message, the following rules are applied in order until a
   match is found:
   <list style="numbers">
      <t>If the request method is GET or HEAD and the response status code is
         <x:ref>200 (OK)</x:ref>, 
         <x:ref>204 (No Content)</x:ref>,
         <x:ref>206 (Partial Content)</x:ref>, or
         <x:ref>304 (Not Modified)</x:ref>,
         the payload is a representation of the resource identified by the
         effective request URI (<xref target="effective.request.uri"/>).</t>
      <t>If the request method is GET or HEAD and the response status code is
         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is
         a potentially modified or enhanced representation of the
         <x:ref>target resource</x:ref> as provided by an intermediary.</t>
      <t>If the response has a <x:ref>Content-Location</x:ref> header field
         and its field-value is a reference to the same URI as the effective
         request URI, the payload is a representation of the resource
         identified by the effective request URI.</t>
      <t>If the response has a <x:ref>Content-Location</x:ref> header field
         and its field-value is a reference to a URI different from the
         effective request URI, then the sender asserts that the payload is a
         representation of the resource identified by the Content-Location
         field-value. However, such an assertion cannot be trusted unless
         it can be verified by other means (not defined by this specification).</t>
      <t>Otherwise, the payload is unidentified.</t>
   </list>
</t>
</section>

<section title="Content-Range" anchor="header.content-range">
  <iref primary="true" item="Content-Range header field" x:for-anchor=""/>
  <x:anchor-alias value="Content-Range"/>
  <x:anchor-alias value="byte-content-range"/>
  <x:anchor-alias value="byte-range-resp"/>
  <x:anchor-alias value="byte-range"/>
  <x:anchor-alias value="unsatisfied-range"/>
  <x:anchor-alias value="complete-length"/>
  <x:anchor-alias value="other-content-range"/>
  <x:anchor-alias value="other-range-resp"/>
<t>
   The "Content-Range" header field is sent in a single part
   <x:ref>206 (Partial Content)</x:ref> response to indicate the partial range
   of the selected representation enclosed as the message payload, sent in
   each part of a multipart 206 response to indicate the range enclosed within
   each body part, and sent in <x:ref>416 (Range Not Satisfiable)</x:ref>
   responses to provide information about the selected representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="byte-content-range"/><iref primary="true" item="Grammar" subitem="byte-range-resp"/><iref primary="true" item="Grammar" subitem="byte-range"/><iref primary="true" item="Grammar" subitem="unsatisfied-range"/><iref primary="true" item="Grammar" subitem="other-content-range"/><iref primary="true" item="Grammar" subitem="other-range-resp"/><iref primary="true" item="Grammar" subitem="complete-length"/>
  <x:ref>Content-Range</x:ref>       = <x:ref>byte-content-range</x:ref>
                      / <x:ref>other-content-range</x:ref>

  <x:ref>byte-content-range</x:ref>  = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref>
                        ( <x:ref>byte-range-resp</x:ref> / <x:ref>unsatisfied-range</x:ref> )

  <x:ref>byte-range-resp</x:ref>     = <x:ref>byte-range</x:ref> "/" ( <x:ref>complete-length</x:ref> / "*" )
  <x:ref>byte-range</x:ref>          = <x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>
  <x:ref>unsatisfied-range</x:ref>   = "*/" <x:ref>complete-length</x:ref>

  <x:ref>complete-length</x:ref>     = 1*<x:ref>DIGIT</x:ref>

  <x:ref>other-content-range</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref> <x:ref>other-range-resp</x:ref>
  <x:ref>other-range-resp</x:ref>    = *<x:ref>CHAR</x:ref>
</artwork></figure>
<t>
   If a <x:ref>206 (Partial Content)</x:ref> response contains a
   <x:ref>Content-Range</x:ref> header field with a <x:ref>range unit</x:ref>
   (<xref target="range.units"/>) that the recipient does not understand, the
   recipient &MUST-NOT; attempt to recombine it with a stored representation.
   A proxy that receives such a message &SHOULD; forward it downstream.
</t>
<t>
   For byte ranges, a sender &SHOULD; indicate the complete length of the
   representation from which the range has been extracted, unless the complete
   length is unknown or difficult to determine. An asterisk character ("*") in
   place of the complete-length indicates that the representation length was
   unknown when the header field was generated.
</t>
<t>
   The following example illustrates when the complete length of the selected
   representation is known by the sender to be 1234 bytes:
</t>
<figure><artwork type="example">
  Content-Range: bytes 42-1233/1234
</artwork></figure>
<t>
   and this second example illustrates when the complete length is unknown:
</t>
<figure><artwork type="example">
  Content-Range: bytes 42-1233/*
</artwork></figure>
<t>
   A Content-Range field value is invalid if it contains a
   <x:ref>byte-range-resp</x:ref> that has a <x:ref>last-byte-pos</x:ref>
   value less than its <x:ref>first-byte-pos</x:ref> value, or a
   <x:ref>complete-length</x:ref> value less than or equal to its
   <x:ref>last-byte-pos</x:ref> value. The recipient of an invalid
   <x:ref>Content-Range</x:ref> &MUST-NOT; attempt to recombine the received
   content with a stored representation.
</t>
<t>
   A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response
   to a byte-range request &SHOULD; send a Content-Range header field with an
   <x:ref>unsatisfied-range</x:ref> value, as in the following example:
</t>
<figure><artwork type="example">
  Content-Range: bytes */1234
</artwork></figure>
<t>
   The complete-length in a 416 response indicates the current length of the
   selected representation.
</t>
<t>
   The Content-Range header field has no meaning for status codes that do
   not explicitly describe its semantic. For this specification, only the
   <x:ref>206 (Partial Content)</x:ref> and
   <x:ref>416 (Range Not Satisfiable)</x:ref> status codes describe a meaning
   for Content-Range.
</t>
<t>
   The following are examples of Content-Range values in which the
   selected representation contains a total of 1234 bytes:
   <list style="symbols">
      <t>
        The first 500 bytes:
<figure><artwork type="example" x:indent-with="   ">
  Content-Range: bytes 0-499/1234
</artwork></figure>
      </t>
      <t>
        The second 500 bytes:
<figure><artwork type="example" x:indent-with="   ">
  Content-Range: bytes 500-999/1234
</artwork></figure>
      </t>
      <t>
        All except for the first 500 bytes:
<figure><artwork type="example" x:indent-with="   ">
  Content-Range: bytes 500-1233/1234
</artwork></figure>
      </t>
      <t>
        The last 500 bytes:
<figure><artwork type="example" x:indent-with="   ">
  Content-Range: bytes 734-1233/1234
</artwork></figure>
      </t>
   </list>
</t>
</section>

<section title="Media Type multipart/byteranges" anchor="multipart.byteranges">
<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
<iref item="multipart/byteranges Media Type" primary="true"/>
<t>
   When a <x:ref>206 (Partial Content)</x:ref> response message includes the
   content of multiple ranges, they are transmitted as body parts in a
   multipart message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>)
   with the media type of "multipart/byteranges".
</t>
<t>
   The multipart/byteranges media type includes one or more body parts, each
   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
   fields. The required boundary parameter specifies the boundary string used
   to separate each body part.
</t>
<t>
  Implementation Notes:
  <list style="numbers">
      <t>Additional CRLFs might precede the first boundary string in the body.</t>

      <t>Although <xref target="RFC2046"/> permits the boundary string to be
         quoted, some existing implementations handle a quoted boundary
         string incorrectly.</t>

      <t>A number of clients and servers were coded to an early draft
         of the byteranges specification that used a media type of
         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>,
         which is almost (but not quite) compatible with this type.</t>
  </list>
</t>
<t>
   Despite the name, the "multipart/byteranges" media type is not limited to
   byte ranges. The following example uses an "exampleunit" range unit:
</t>
<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 1.2-4.3/25

...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25

...the second range
--THIS_STRING_SEPARATES--
</artwork>
</figure>
<t>
  The following information serves as the registration form for the
  multipart/byteranges media type.
</t>
<t>
  <list style="hanging" x:indent="12em">
    <t hangText="Type name:">
      multipart
    </t>
    <t hangText="Subtype name:">
      byteranges
    </t>
    <t hangText="Required parameters:">
      boundary
    </t>
    <t hangText="Optional parameters:">
      N/A
    </t>
    <t hangText="Encoding considerations:">
      only "7bit", "8bit", or "binary" are permitted
    </t>
    <t hangText="Security considerations:">
      see <xref target="security.considerations"/>
    </t>
    <t hangText="Interoperability considerations:">
      N/A
    </t>
    <t hangText="Published specification:">
      This specification (see <xref target="multipart.byteranges"/>).
    </t>
    <t hangText="Applications that use this media type:">
      HTTP components supporting multiple ranges in a single request.
    </t>
    <t hangText="Fragment identifier considerations:">
      N/A
    </t>
    <t hangText="Additional information:">
      <list style="hanging">
        <t hangText="Deprecated alias names for this type:">N/A</t>
        <t hangText="Magic number(s):">N/A</t>
        <t hangText="File extension(s):">N/A</t>
        <t hangText="Macintosh file type code(s):">N/A</t>
      </list>
    </t>
    <t hangText="Person and email address to contact for further information:">
      See Authors' Addresses section.
    </t>
    <t hangText="Intended usage:">
      COMMON
    </t>
    <t hangText="Restrictions on usage:">
      N/A
    </t>
    <t hangText="Author:">
      See Authors' Addresses section.
    </t>
    <t hangText="Change controller:">
      IESG
    </t>
  </list>
</t>
</section>
</section>

<section title="Content Negotiation" anchor="content.negotiation">
  <x:anchor-alias value="content negotiation"/>
<t>
   When responses convey payload information, whether indicating a success or
   an error, the origin server often has different ways of representing that
   information; for example, in different formats, languages, or encodings.
   Likewise, different users or user agents might have differing capabilities,
   characteristics, or preferences that could influence which representation,
   among those available, would be best to deliver. For this reason, HTTP
   provides mechanisms for <x:ref>content negotiation</x:ref>.
</t>
<t>
   This specification defines two patterns of content negotiation that can
   be made visible within the protocol:
   "proactive", where the server selects the representation based
   upon the user agent's stated preferences, and "reactive" negotiation,
   where the server provides a list of representations for the user agent to
   choose from. Other patterns of content negotiation include
   "conditional content", where the representation consists of multiple
   parts that are selectively rendered based on user agent parameters, 
   "active content", where the representation contains a script that
   makes additional (more specific) requests based on the user agent
   characteristics, and "Transparent Content Negotiation"
   (<xref target="RFC2295"/>), where content selection is performed by
   an intermediary. These patterns are not mutually exclusive, and each has
   trade-offs in applicability and practicality.
</t>
<t>
   Note that, in all cases, HTTP is not aware of the resource semantics.
   The consistency with which an origin server responds to requests, over time
   and over the varying dimensions of content negotiation, and thus the
   "sameness" of a resource's observed representations over time, is
   determined entirely by whatever entity or algorithm selects or generates
   those responses. HTTP pays no attention to the man behind the curtain.
</t>

<section title="Proactive Negotiation" anchor="proactive.negotiation">
  <x:anchor-alias value="proactive negotiation"/>
  <x:anchor-alias value="server-driven negotiation"/>
<t>
   When content negotiation preferences are sent by the user agent in a
   request to encourage an algorithm located at the server to
   select the preferred representation, it is called
   <x:dfn>proactive negotiation</x:dfn>
   (a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on
   the available representations for a response (the dimensions over which it
   might vary, such as language, content-coding, etc.) compared to various
   information supplied in the request, including both the explicit
   negotiation fields of <xref target="request.conneg"/> and implicit
   characteristics, such as the client's network address or parts of the
   <x:ref>User-Agent</x:ref> field.
</t>
<t>
   Proactive negotiation is advantageous when the algorithm for
   selecting from among the available representations is difficult to
   describe to a user agent, or when the server desires to send its
   "best guess" to the user agent along with the first response (hoping to
   avoid the round trip delay of a subsequent request if the "best
   guess" is good enough for the user). In order to improve the server's
   guess, a user agent &MAY; send request header fields that describe
   its preferences.
</t>
<t>
   Proactive negotiation has serious disadvantages:
  <list style="symbols">
    <t>
         It is impossible for the server to accurately determine what
         might be "best" for any given user, since that would require
         complete knowledge of both the capabilities of the user agent
         and the intended use for the response (e.g., does the user want
         to view it on screen or print it on paper?);
    </t>
    <t>
         Having the user agent describe its capabilities in every
         request can be both very inefficient (given that only a small
         percentage of responses have multiple representations) and a
         potential risk to the user's privacy;
    </t>
    <t>
         It complicates the implementation of an origin server and the
         algorithms for generating responses to a request; and,
    </t>
    <t>
         It limits the reusability of responses for shared caching.
    </t>
  </list>
</t>
<t>
   A user agent cannot rely on proactive negotiation preferences being
   consistently honored, since the origin server might not implement proactive
   negotiation for the requested resource or might decide that sending a
   response that doesn't conform to the user agent's preferences is better
   than sending a <x:ref>406 (Not Acceptable)</x:ref> response.
</t>
<t>
   A <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>) is
   often sent in a response subject to proactive negotiation to indicate what
   parts of the request information were used in the selection algorithm.
</t>
</section>

<section title="Reactive Negotiation" anchor="reactive.negotiation">
  <x:anchor-alias value="reactive negotiation"/>
  <x:anchor-alias value="agent-driven negotiation"/>
<t>
   With <x:dfn>reactive negotiation</x:dfn>
   (a.k.a., <x:dfn>agent-driven negotiation</x:dfn>), selection of the best
   response representation (regardless of the status code) is performed by the
   user agent after receiving an initial response from the origin server that
   contains a list of resources for alternative representations.
   If the user agent is not satisfied by the initial response representation,
   it can perform a GET request on one or more of the alternative resources,
   selected based on metadata included in the list, to obtain a different form
   of representation for that response. Selection of alternatives might be
   performed automatically by the user agent or manually by the user selecting
   from a generated (possibly hypertext) menu.
</t>
<t>
   Note that the above refers to representations of the response, in general,
   not representations of the resource. The alternative representations are
   only considered representations of the target resource if the response in
   which those alternatives are provided has the semantics of being a
   representation of the target resource (e.g., a <x:ref>200 (OK)</x:ref>
   response to a GET request) or has the semantics of providing links to
   alternative representations for the target resource
   (e.g., a <x:ref>300 (Multiple Choices)</x:ref> response to a GET request).
</t>
<t>
   A server might choose not to send an initial representation, other than
   the list of alternatives, and thereby indicate that reactive
   negotiation by the user agent is preferred. For example, the alternatives
   listed in responses with the <x:ref>300 (Multiple Choices)</x:ref> and
   <x:ref>406 (Not Acceptable)</x:ref> status codes include information about
   the available representations so that the user or user agent can react by
   making a selection.
</t>
<t>
   Reactive negotiation is advantageous when the response would vary
   over commonly used dimensions (such as type, language, or encoding),
   when the origin server is unable to determine a user agent's
   capabilities from examining the request, and generally when public
   caches are used to distribute server load and reduce network usage.
</t>
<t>
   Reactive negotiation suffers from the disadvantages of transmitting
   a list of alternatives to the user agent, which degrades user-perceived
   latency if transmitted in the header section, and needing a second request
   to obtain an alternate representation. Furthermore, this specification
   does not define a mechanism for supporting automatic selection, though it
   does not prevent such a mechanism from being developed as an extension.
</t>
</section>
</section>
</section>

<section title="Request Methods" anchor="methods">

<section title="Overview" anchor="method.overview">
  <x:anchor-alias value="method"/>
<t>
   The request method token is the primary source of request semantics;
   it indicates the purpose for which the client has made this request
   and what is expected by the client as a successful result.
</t>
<t>
   The request method's semantics might be further specialized by the
   semantics of some header fields when present in a request
   (<xref target="request.header.fields"/>) if those additional semantics do
   not conflict with the method.
   For example, a client can send conditional request header fields
   (<xref target="preconditions"/>) to make the requested
   action conditional on the current state of the target resource.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="method"/>
  <x:ref>method</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t>
   HTTP was originally designed to be usable as an interface to distributed
   object systems.  The request method was envisioned as applying
   semantics to a <x:ref>target resource</x:ref> in much the same way as invoking a defined
   method on an identified object would apply semantics. The method token
   is case-sensitive because it might be used as a gateway to object-based
   systems with case-sensitive method names.
</t>
<t>
   Unlike distributed objects, the standardized request methods in HTTP are
   not resource-specific, since uniform interfaces provide for better
   visibility and reuse in network-based systems <xref target="REST"/>.
   Once defined, a standardized method ought to have the same semantics when
   applied to any resource, though each resource determines for itself
   whether those semantics are implemented or allowed.
</t>
<t>
   This specification defines a number of standardized methods that are
   commonly used in HTTP, as outlined by the following table. By convention,
   standardized methods are defined in all-uppercase US-ASCII letters.
</t>
<texttable align="left" suppress-title="true" anchor="table.of.methods">
   <ttcol>Method</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Sec.</ttcol>
   <c>GET</c>
   <c>Transfer a current representation of the target resource.</c>
   <c><xref target="GET" format="counter"/></c>
   <c>HEAD</c>
   <c>Same as GET, but only transfer the status line and header section.</c>
   <c><xref target="HEAD" format="counter"/></c>
   <c>POST</c>
   <c>Perform resource-specific processing on the request payload.</c>
   <c><xref target="POST" format="counter"/></c>
   <c>PUT</c>
   <c>Replace all current representations of the target resource with
      the request payload.</c>
   <c><xref target="PUT" format="counter"/></c>
   <c>DELETE</c>
   <c>Remove all current representations of the target resource.</c>
   <c><xref target="DELETE" format="counter"/></c>
   <c>CONNECT</c>
   <c>Establish a tunnel to the server identified by the target resource.</c>
   <c><xref target="CONNECT" format="counter"/></c>
   <c>OPTIONS</c>
   <c>Describe the communication options for the target resource.</c>
   <c><xref target="OPTIONS" format="counter"/></c>
   <c>TRACE</c>
   <c>Perform a message loop-back test along the path to the target resource.</c>
   <c><xref target="TRACE" format="counter"/></c>
</texttable>
<t>
   All general-purpose servers &MUST; support the methods GET and HEAD.
   All other methods are &OPTIONAL;.
</t>
<t>
   The set of methods allowed by a target resource can be listed in an
   <x:ref>Allow</x:ref> header field (<xref target="header.allow"/>).
   However, the set of allowed methods can change dynamically.
   When a request method is received that is unrecognized or not implemented
   by an origin server, the origin server &SHOULD; respond with the
   <x:ref>501 (Not Implemented)</x:ref> status code.
   When a request method is received that is known by an origin server but
   not allowed for the target resource, the origin server &SHOULD; respond
   with the <x:ref>405 (Method Not Allowed)</x:ref> status code.
</t>
</section>

<section title="Common Method Properties" anchor="method.properties">
<?BEGININC build/draft-ietf-httpbis-semantics-latest.iana-methods ?>
<!--AUTOGENERATED FROM extract-method-defs.xslt, do not edit manually-->
<texttable align="left"
           suppress-title="true"
           anchor="iana.method.registration.table">
   <ttcol>Method</ttcol>
   <ttcol>Safe</ttcol>
   <ttcol>Idempotent</ttcol>
   <ttcol>Reference</ttcol>
   <c>CONNECT</c>
   <c>no</c>
   <c>no</c>
   <c>
      <xref target="CONNECT"/>
   </c>
   <c>DELETE</c>
   <c>no</c>
   <c>yes</c>
   <c>
      <xref target="DELETE"/>
   </c>
   <c>GET</c>
   <c>yes</c>
   <c>yes</c>
   <c>
      <xref target="GET"/>
   </c>
   <c>HEAD</c>
   <c>yes</c>
   <c>yes</c>
   <c>
      <xref target="HEAD"/>
   </c>
   <c>OPTIONS</c>
   <c>yes</c>
   <c>yes</c>
   <c>
      <xref target="OPTIONS"/>
   </c>
   <c>POST</c>
   <c>no</c>
   <c>no</c>
   <c>
      <xref target="POST"/>
   </c>
   <c>PUT</c>
   <c>no</c>
   <c>yes</c>
   <c>
      <xref target="PUT"/>
   </c>
   <c>TRACE</c>
   <c>yes</c>
   <c>yes</c>
   <c>
      <xref target="TRACE"/>
   </c>
</texttable>
<!--(END)-->

<?ENDINC build/draft-ietf-httpbis-semantics-latest.iana-methods ?>

<section title="Safe Methods" anchor="safe.methods">
  <iref item="safe" primary="true"/>
  <x:anchor-alias value="safe"/>
<t>
   Request methods are considered "<x:dfn>safe</x:dfn>" if
   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
   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,
   loss of property, or unusual burden on the origin server.
</t>
<t>
   This definition of safe methods does not prevent an implementation from
   including behavior that is potentially harmful, that is not entirely read-only,
   or that causes side effects while invoking a safe method.  What is
   important, however, is that the client did not request that additional
   behavior and cannot be held accountable for it.  For example,
   most servers append request information to access log files at the
   completion of every response, regardless of the method, and that is
   considered safe even though the log storage might become full and crash
   the server.  Likewise, a safe request initiated by selecting an
   advertisement on the Web will often have the side effect of charging an
   advertising account.
</t>
<t>
   Of the request methods defined by this specification, the
   GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
</t>
<t>
   The purpose of distinguishing between safe and unsafe methods is to
   allow automated retrieval processes (spiders) and cache performance
   optimization (pre-fetching) to work without fear of causing harm.
   In addition, it allows a user agent to apply appropriate constraints
   on the automated use of unsafe methods when processing potentially
   untrusted content.
</t>
<t>
   A user agent &SHOULD; distinguish between safe and unsafe methods when
   presenting potential actions to a user, such that the user can be made
   aware of an unsafe action before it is requested.
</t>
<t>
   When a resource is constructed such that parameters within the effective
   request URI have the effect of selecting an action, it is the resource
   owner's responsibility to ensure that the action is consistent with the
   request method semantics.
   For example, it is common for Web-based content editing software
   to use actions within query parameters, such as "page?do=delete".
   If the purpose of such a resource is to perform an unsafe action, then
   the resource owner &MUST; disable or disallow that action when it is
   accessed using a safe request method. Failure to do so will result in
   unfortunate side effects when automated processes perform a GET on
   every URI reference for the sake of link maintenance, pre-fetching,
   building a search index, etc.
</t>
</section>

<section title="Idempotent Methods" anchor="idempotent.methods">
<iref item="idempotent" primary="true"/>
<t>
   A request method is considered
   "<x:dfn anchor="idempotent">idempotent</x:dfn>"
   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.
   Of the request methods defined by this
   specification, PUT, DELETE, and safe request methods are idempotent.
</t>
<t>
   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
   separately, retain a revision control history, or implement other
   non-idempotent side effects for each idempotent request.
</t>
<t>
   Idempotent methods are distinguished because the request can be repeated
   automatically if a communication failure occurs before the client is
   able to read the server's response.  For example, if a client sends a PUT
   request and the underlying connection is closed before any response is
   received, then the client can establish a new connection and retry the
   idempotent request. It knows that repeating the request will have
   the same intended effect, even if the original request succeeded, though
   the response might differ.
</t>
</section>

<section title="Cacheable Methods" anchor="cacheable.methods">
<iref item="cacheable" primary="true"/>
<t>
   Request methods can be defined as "<x:dfn
   anchor="cacheable">cacheable</x:dfn>" to indicate that responses to them are
   allowed to be stored for future reuse; for specific requirements see
   <xref target="Caching"/>. In general, safe methods that do not depend on a current or
   authoritative response are defined as cacheable; this specification defines
   GET, HEAD, and POST as cacheable, although the overwhelming majority of 
   cache implementations only support GET and HEAD.
</t>
</section>
</section>

<section title="Method Definitions" anchor="method.definitions">

<section title="GET" anchor="GET">
  <rdf:Description>
    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="GET method" x:for-anchor=""/>
<t>
   The GET method requests transfer of a current selected representation for
   the <x:ref>target resource</x:ref>. GET is the primary mechanism of
   information retrieval and the focus of almost all performance
   optimizations. Hence, when people speak of retrieving some identifiable
   information via HTTP, they are generally referring to making a GET request.
</t>
<t>
   It is tempting to think of resource identifiers as remote file system
   pathnames and of representations as being a copy of the contents of such
   files. In fact, that is how many resources are implemented (see
   <xref target="attack.pathname"/> for related security considerations).
   However, there are no such limitations in practice. The HTTP interface for
   a resource is just as likely to be implemented as a tree of content
   objects, a programmatic view on various database records, or a gateway to
   other information systems. Even when the URI mapping mechanism is tied to a
   file system, an origin server might be configured to execute the files with
   the request as input and send the output as the representation rather than
   transfer the files directly. Regardless, only the origin server needs to
   know how each of its resource identifiers corresponds to an implementation
   and how each implementation manages to select and send a current
   representation of the target resource in a response to GET.
</t>
<t>
   A client can alter the semantics of GET to be a "range request", requesting
   transfer of only some part(s) of the selected representation, by sending a
   <x:ref>Range</x:ref> header field in the request (<xref target="header.range"/>).
</t>
<t>
   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.
</t>
<t>
   The response to a GET request is cacheable; a cache &MAY; use it to satisfy
   subsequent GET and HEAD requests unless otherwise indicated by the
   Cache-Control header field (<xref target="header.cache-control"/>).
</t>
</section>

<section title="HEAD" anchor="HEAD">
  <rdf:Description>
    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="HEAD method" x:for-anchor=""/>
<t>
   The HEAD method is identical to GET except that the server &MUST-NOT;
   send a message body in the response (i.e., the response terminates at the
   end of the header section). The server &SHOULD; send the same header fields
   in response to a HEAD request as it would have sent if the request had been
   a GET, except that the payload header fields (<xref target="payload"/>)
   &MAY; be omitted. This method can be used for obtaining metadata about the
   selected representation without transferring the representation data and is
   often used for testing hypertext links for validity, accessibility, and
   recent modification.
</t>
<t>
   A payload within a HEAD request message has no defined semantics;
   sending a payload body on a HEAD request might cause some existing
   implementations to reject the request.
</t>
<t>
   The response to a HEAD request is cacheable; a cache &MAY; use it to
   satisfy subsequent HEAD requests unless otherwise indicated by the
   Cache-Control header field (<xref target="header.cache-control"/>). A HEAD response might
   also have an effect on previously cached responses to GET; see <xref target="head.effects"/>.
</t>
</section>

<section title="POST" anchor="POST">
  <iref primary="true" item="POST method" x:for-anchor=""/>
<t>
   The POST method requests that the <x:ref>target resource</x:ref> process
   the representation enclosed in the request according to the resource's own
   specific semantics. For example, POST is used for the following functions
   (among others):
  <list style="symbols">
    <t>Providing a block of data, such as the fields entered into an HTML
       form, to a data-handling process;</t>
    <t>Posting a message to a bulletin board, newsgroup, mailing list, blog,
       or similar group of articles;</t>
    <t>Creating a new resource that has yet to be identified by the origin
       server; and</t>
    <t>Appending data to a resource's existing representation(s).</t>
  </list>
</t>
<t>
   An origin server indicates response semantics by choosing an appropriate
   status code depending on the result of processing the POST request;
   almost all of the status codes defined by this specification might be
   received in a response to POST (the exceptions being <x:ref>206 (Partial Content)</x:ref>,
   <x:ref>304 (Not Modified)</x:ref>, and <x:ref>416 (Range Not Satisfiable)</x:ref>).
</t>
<t>
   If one or more resources has been created on the origin server as a result
   of successfully processing a POST request, the origin server &SHOULD; send
   a <x:ref>201 (Created)</x:ref> response containing a <x:ref>Location</x:ref>
   header field that provides an identifier for the primary resource created
   (<xref target="header.location"/>) and a representation that describes the
   status of the request while referring to the new resource(s).
</t>
<t>
   Responses to POST requests are only cacheable when they include explicit
   freshness information (see <xref target="calculating.freshness.lifetime"/>). However, POST caching is not
   widely implemented. For cases where an origin server wishes the client to
   be able to cache the result of a POST in a way that can be reused by a
   later GET, the origin server &MAY; send a <x:ref>200 (OK)</x:ref> response
   containing the result and a <x:ref>Content-Location</x:ref> header field
   that has the same value as the POST's effective request URI
   (<xref target="header.content-location"/>).
</t>
<t>
   If the result of processing a POST would be equivalent to a representation
   of an existing resource, an origin server &MAY; redirect the user agent to
   that resource by sending a <x:ref>303 (See Other)</x:ref> response with the
   existing resource's identifier in the <x:ref>Location</x:ref> field.
   This has the benefits of providing the user agent a resource identifier
   and transferring the representation via a method more amenable to shared
   caching, though at the cost of an extra request if the user agent does not
   already have the representation cached.
</t>
</section>

<section title="PUT" anchor="PUT">
  <rdf:Description>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="PUT method" x:for-anchor=""/>
<t>
   The PUT method requests that the state of the <x:ref>target resource</x:ref>
   be created or replaced with the state defined by the representation
   enclosed in the request message payload.  A successful PUT of a given
   representation would suggest that a subsequent GET on that same target
   resource will result in an equivalent representation being sent in
   a <x:ref>200 (OK)</x:ref> response.  However, there is no guarantee that
   such a state change will be observable, since the target resource might be
   acted upon by other user agents in parallel, or might be subject to dynamic
   processing by the origin server, before any subsequent GET is received.
   A successful response only implies that the user agent's intent was
   achieved at the time of its processing by the origin server.
</t>
<t>   
   If the target resource does not have a current representation and
   the PUT successfully creates one, then the origin server &MUST; inform
   the user agent by sending a <x:ref>201 (Created)</x:ref> response.  If the
   target resource does have a current representation and that representation is
   successfully modified in accordance with the state of the enclosed
   representation, then the origin server &MUST; send either a
   <x:ref>200 (OK)</x:ref> or a <x:ref>204 (No Content)</x:ref> response to
   indicate successful completion of the request.
</t>
<t>
   An origin server &SHOULD; ignore unrecognized header fields received in a
   PUT request (i.e., do not save them as part of the resource state).
</t>
<t>
   An origin server &SHOULD; verify that the PUT representation is
   consistent with any constraints the server has for the target
   resource that cannot or will not be changed by the PUT.  This is
   particularly important when the origin server uses internal
   configuration information related to the URI in order to set the
   values for representation metadata on GET responses.  When a PUT
   representation is inconsistent with the target resource, the origin
   server &SHOULD; either make them consistent, by transforming the
   representation or changing the resource configuration, or respond
   with an appropriate error message containing sufficient information
   to explain why the representation is unsuitable.  The
   <x:ref>409 (Conflict)</x:ref> or <x:ref>415 (Unsupported Media Type)</x:ref>
   status codes are suggested, with the latter being specific to constraints on
   <x:ref>Content-Type</x:ref> values.
</t>
<t>
   For example, if the target resource is configured to always have a
   <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT
   has a Content-Type of "image/jpeg", the origin server ought to do one of:
   <list style="letters">
      <t>reconfigure the target resource to reflect the new media type;</t>
      <t>transform the PUT representation to a format consistent with that
         of the resource before saving it as the new resource state; or,</t>
      <t>reject the request with a <x:ref>415 (Unsupported Media Type)</x:ref>
         response indicating that the target resource is limited to "text/html",
         perhaps including a link to a different resource that would be a
         suitable target for the new representation.</t>
   </list>
</t>
<t>
   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
   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
   word, beyond the interface provided via HTTP.  It does not define
   how resource state is "stored", nor how such storage might change
   as a result of a change in resource state, nor how the origin server
   translates resource state into representations.  Generally speaking,
   all implementation details behind the resource interface are
   intentionally hidden by the server.
</t>
<t>
   An origin server &MUST-NOT; send a validator header field
   (<xref target="response.validator"/>), such as an <x:ref>ETag</x:ref> or
   <x:ref>Last-Modified</x:ref> field, in a successful response to PUT unless
   the request's representation data was saved without any transformation
   applied to the body (i.e., the resource's new representation data is
   identical to the representation data received in the PUT request) and the
   validator field value reflects the new representation.
   This requirement allows a user agent to know when the representation body
   it has in memory remains current as a result of the PUT, thus not in need
   of being retrieved again from the origin server, and that the new validator(s)
   received in the response can be used for future conditional requests in
   order to prevent accidental overwrites (<xref target="preconditions"/>).
</t>
<t>
   The fundamental difference between the POST and PUT methods is
   highlighted by the different intent for the enclosed representation.
   The target resource in a POST request is intended to handle the
   enclosed representation according to the resource's own semantics,
   whereas the enclosed representation in a PUT request is defined as
   replacing the state of the target resource. Hence, the intent of PUT is
   idempotent and visible to intermediaries, even though the exact effect is
   only known by the origin server.
</t>
<t>
   Proper interpretation of a PUT request presumes that the user agent knows
   which target resource is desired. A service that selects a proper URI on
   behalf of the client, after receiving a state-changing request, &SHOULD; be
   implemented using the POST method rather than PUT. If the origin server
   will not make the requested PUT state change to the target resource and
   instead wishes to have it applied to a different resource, such as when the
   resource has been moved to a different URI, then the origin server &MUST;
   send an appropriate <x:ref>3xx (Redirection)</x:ref> response; the
   user agent &MAY; then make its own decision regarding whether or not to
   redirect the request.
</t>
<t>
   A PUT request applied to the target resource can have side effects
   on other resources.  For example, an article might have a URI for
   identifying "the current version" (a resource) that is separate
   from the URIs identifying each particular version (different
   resources that at one point shared the same state as the current version
   resource).  A successful PUT request on "the current version" URI might
   therefore create a new version resource in addition to changing the
   state of the target resource, and might also cause links to be added
   between the related resources.
</t>
<t>
   An origin server that allows PUT on a given target resource &MUST; send a
   <x:ref>400 (Bad Request)</x:ref> response to a PUT request that contains a
   <x:ref>Content-Range</x:ref> header field (<xref target="header.content-range"/>), since
   the payload is likely to be partial content that has been mistakenly PUT as
   a full representation.
   Partial content updates are possible by targeting a separately identified
   resource with state that overlaps a portion of the larger resource, or by
   using a different method that has been specifically defined for partial
   updates (for example, the PATCH method defined in
   <xref target="RFC5789"/>).
</t>
<t>
   Responses to the PUT method are not cacheable. If a successful PUT request
   passes through a cache that has one or more stored responses for the
   effective request URI, those stored responses will be invalidated
   (see <xref target="invalidation"/>).
</t>
</section>

<section title="DELETE" anchor="DELETE">
  <rdf:Description>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="DELETE method" x:for-anchor=""/>
<t>
   The DELETE method requests that the origin server remove the association
   between the <x:ref>target resource</x:ref> and its current functionality.
   In effect, this method is similar to the rm command in UNIX: it expresses a
   deletion operation on the URI mapping of the origin server rather than an
   expectation that the previously associated information be deleted.
</t>
<t>
   If the target resource has one or more current representations, they might
   or might not be destroyed by the origin server, and the associated storage
   might or might not be reclaimed, depending entirely on the nature of the
   resource and its implementation by the origin server (which are beyond the
   scope of this specification). Likewise, other implementation aspects of a
   resource might need to be deactivated or archived as a result of a DELETE,
   such as database or gateway connections. In general, it is assumed that the
   origin server will only allow DELETE on resources for which it has a
   prescribed mechanism for accomplishing the deletion.
</t>
<t>
   Relatively few resources allow the DELETE method &mdash; its primary use
   is for remote authoring environments, where the user has some direction
   regarding its effect. For example, a resource that was previously created
   using a PUT request, or identified via the Location header field after a
   <x:ref>201 (Created)</x:ref> response to a POST request, might allow a
   corresponding DELETE request to undo those actions.  Similarly, custom
   user agent implementations that implement an authoring function, such as
   revision control clients using HTTP for remote operations, might use
   DELETE based on an assumption that the server's URI space has been crafted
   to correspond to a version repository.
</t>
<t>
   If a DELETE method is successfully applied, the origin server &SHOULD; send
   a <x:ref>202 (Accepted)</x:ref> status code if the action will likely succeed but
   has not yet been enacted,
   a <x:ref>204 (No Content)</x:ref> status code if the action has been
   enacted and no further information is to be supplied, or
   a <x:ref>200 (OK)</x:ref> status code if the action has been enacted and
   the response message includes a representation describing the status.
</t>
<t>
   A payload within a DELETE request message has no defined semantics;
   sending a payload body on a DELETE request might cause some existing
   implementations to reject the request.
</t>
<t>
   Responses to the DELETE method are not cacheable. If a DELETE request 
   passes through a cache that has one or more stored responses for the 
   effective request URI, those stored responses will be invalidated (see
   <xref target="invalidation"/>).
</t>
</section>

<section title="CONNECT" anchor="CONNECT">
  <iref primary="true" item="CONNECT method" x:for-anchor=""/>
<t>
   The CONNECT method requests that the recipient establish a tunnel to the
   destination origin server identified by the request-target and, if
   successful, thereafter restrict its behavior to blind forwarding of
   packets, in both directions, until the tunnel is closed.
   Tunnels are commonly used to create an end-to-end virtual connection,
   through one or more proxies, which can then be secured using TLS
   (Transport Layer Security, <xref target="RFC5246"/>).
</t>
<t>
   CONNECT is intended only for use in requests to a proxy.
   An origin server that receives a CONNECT request for itself &MAY;
   respond with a <x:ref>2xx (Successful)</x:ref> status code to indicate that a connection
   is established.  However, most origin servers do not implement CONNECT.
</t>
<t>
   A client sending a CONNECT request &MUST; send the authority form of
   request-target (<xref target="request.target"/>); i.e., the request-target consists
   of only the host name and port number of the tunnel destination, separated
   by a colon. For example,
</t>
<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

</artwork></figure>
<t>
   The recipient proxy can establish a tunnel either by directly connecting to
   the request-target or, if configured to use another proxy, by forwarding
   the CONNECT request to the next inbound proxy.
   Any <x:ref>2xx (Successful)</x:ref> response indicates
   that the sender (and all inbound proxies) will switch to tunnel mode
   immediately after the blank line that concludes the successful response's
   header section; data received after that blank line is from the server
   identified by the request-target.
   Any response other than a successful response indicates that the tunnel
   has not yet been formed and that the connection remains governed by HTTP.
</t>
<t>
   A tunnel is closed when a tunnel intermediary detects that either side
   has closed its connection: the intermediary &MUST; attempt to send any
   outstanding data that came from the closed side to the other side, close
   both connections, and then discard any remaining data left undelivered.
</t>
<t>
   Proxy authentication might be used to establish the
   authority to create a tunnel.  For example,
</t>
<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=

</artwork></figure>
<t>
   There are significant risks in establishing a tunnel to arbitrary servers,
   particularly when the destination is a well-known or reserved TCP port that
   is not intended for Web traffic. For example, a CONNECT to a request-target
   of "example.com:25" would suggest that the proxy connect to the reserved
   port for SMTP traffic; if allowed, that could trick the proxy into
   relaying spam email. Proxies that support CONNECT &SHOULD; restrict its
   use to a limited set of known ports or a configurable whitelist of safe
   request targets.
</t>
<t>
   A server &MUST-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
   <x:ref>Content-Length</x:ref> header fields in a
   <x:ref>2xx (Successful)</x:ref> response to CONNECT.
   A client &MUST; ignore any Content-Length or Transfer-Encoding header
   fields received in a successful response to CONNECT.
</t>
<t>
   A payload within a CONNECT request message has no defined semantics;
   sending a payload body on a CONNECT request might cause some existing
   implementations to reject the request.
</t>
<t>
   Responses to the CONNECT method are not cacheable.
</t>
</section>

<section title="OPTIONS" anchor="OPTIONS">
  <rdf:Description>
    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
<t>
   The OPTIONS method requests information about the communication options
   available for the target resource, at either the origin server or an
   intervening intermediary. This method allows a client to determine the
   options and/or requirements associated with a resource, or the capabilities
   of a server, without implying a resource action.
</t>
<t>
   An OPTIONS request with an asterisk ("*") as the request-target
   (<xref target="request.target"/>) applies to the server in general rather than to a
   specific resource. Since a server's communication options typically depend
   on the resource, the "*" request is only useful as a "ping" or "no-op"
   type of method; it does nothing beyond allowing the client to test
   the capabilities of the server. For example, this can be used to test
   a proxy for HTTP/1.1 conformance (or lack thereof).
</t>
<t>
   If the request-target is not an asterisk, the OPTIONS request applies
   to the options that are available when communicating with the target
   resource.
</t>
<t>
   A server generating a successful response to OPTIONS &SHOULD; send any
   header fields that might indicate optional features implemented by the
   server and applicable to the target resource (e.g., <x:ref>Allow</x:ref>),
   including potential extensions not defined by this specification.
   The response payload, if any, might also describe the communication options
   in a machine or human-readable representation. A standard format for such a
   representation is not defined by this specification, but might be defined by
   future extensions to HTTP.
   A server &MUST; generate a <x:ref>Content-Length</x:ref> field with a value
   of "0" if no payload body is to be sent in the response.
</t>
<t>
   A client &MAY; send a <x:ref>Max-Forwards</x:ref> header field in an
   OPTIONS request to target a specific recipient in the request chain (see
   <xref target="header.max-forwards"/>). A proxy &MUST-NOT; generate a
   Max-Forwards header field while forwarding a request unless that request
   was received with a Max-Forwards field.
</t>
<t>
   A client that generates an OPTIONS request containing a payload body
   &MUST; send a valid <x:ref>Content-Type</x:ref> header field describing
   the representation media type. Although this specification does not define
   any use for such a payload, future extensions to HTTP might use the OPTIONS
   body to make more detailed queries about the target resource.
</t>
<t>
   Responses to the OPTIONS method are not cacheable.
</t>
</section>

<section title="TRACE" anchor="TRACE">
  <rdf:Description>
    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    <idempotent xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</idempotent>
  </rdf:Description>
  <iref primary="true" item="TRACE method" x:for-anchor=""/>
<t>
   The TRACE method requests a remote, application-level loop-back of the
   request message. The final recipient of the request &SHOULD; reflect the
   message received, excluding some fields described below, back to the client
   as the message body of a <x:ref>200 (OK)</x:ref> response with a
   <x:ref>Content-Type</x:ref> of "message/http" (<xref target="media.type.message.http"/>).
   The final recipient is either the origin server or the first server to
   receive a <x:ref>Max-Forwards</x:ref> value of zero (0) in the request
   (<xref target="header.max-forwards"/>).
</t>
<t>
   A client &MUST-NOT; generate header fields in a TRACE request containing
   sensitive data that might be disclosed by the response. For example, it
   would be foolish for a user agent to send stored user credentials
   <xref target="request.auth"/> or cookies <xref target="RFC6265"/> in a TRACE
   request. The final recipient of the request &SHOULD; exclude any request
   header fields that are likely to contain sensitive data when that recipient
   generates the response body.
</t>
<t>
   TRACE allows the client to see what is being received at the other
   end of the request chain and use that data for testing or diagnostic
   information. The value of the <x:ref>Via</x:ref> header field (<xref target="header.via"/>)
   is of particular interest, since it acts as a trace of the request chain.
   Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
   limit the length of the request chain, which is useful for testing a chain
   of proxies forwarding messages in an infinite loop.
</t>
<t>
   A client &MUST-NOT; send a message body in a TRACE request.
</t>
<t>
   Responses to the TRACE method are not cacheable.
</t>
</section>
</section>

<section title="Method Extensibility" anchor="method.extensibility">
<t>
   Additional methods, outside the scope of this specification, have been
   specified for use in HTTP. All such methods ought to be registered
   within the "Hypertext Transfer Protocol (HTTP) Method Registry".
</t>

<section title="Method Registry" anchor="method.registry">
<t>
  The "Hypertext Transfer Protocol (HTTP) Method Registry", maintained by
  IANA at <eref target="https://www.iana.org/assignments/http-methods"/>,
  registers <x:ref>method</x:ref> names.
</t>
<t>
  HTTP method registrations &MUST; include the following fields:
  <list style="symbols">
    <t>Method Name (see <xref target="methods"/>)</t>
    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
    <t>Idempotent ("yes" or "no", see <xref target="idempotent.methods"/>)</t>
    <t>Pointer to specification text</t>
  </list>
</t>
<t>
  Values to be added to this namespace require IETF Review
  (see <xref target="RFC8126" x:fmt="," x:sec="4.8"/>).
</t>
</section>

<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
<t>
   Standardized methods are generic; that is, they are potentially
   applicable to any resource, not just one particular media type, kind of
   resource, or application. As such, it is preferred that new methods
   be registered in a document that isn't specific to a single application or
   data format, since orthogonal technologies deserve orthogonal specification.
</t>
<t>
   Since message parsing (<xref target="message.body"/>) needs to be independent of method
   semantics (aside from responses to HEAD), definitions of new methods
   cannot change the parsing algorithm or prohibit the presence of a message
   body on either the request or the response message.
   Definitions of new methods can specify that only a zero-length message body
   is allowed by requiring a Content-Length header field with a value of "0".
</t>
<t>
   A new method definition needs to indicate whether it is safe (<xref
   target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
   cacheable (<xref target="cacheable.methods"/>), what
   semantics are to be associated with the payload body if any is present
   in the request and what refinements the method makes to header field
   or status code semantics.
   If the new method is cacheable, its definition ought to describe how, and
   under what conditions, a cache can store a response and use it to satisfy a
   subsequent request.
   The new method ought to describe whether it can be made conditional
   (<xref target="preconditions"/>) and, if so, how a server responds
   when the condition is false.
   Likewise, if the new method might have some use for partial response
   semantics (<xref target="header.range"/>), it ought to document this, too.
</t>
<aside>
  <t>
    &Note; Avoid defining a method name that starts with "M-", since that
    prefix might be misinterpreted as having the semantics assigned to it
    by <xref target="RFC2774"/>.
  </t>
</aside>
</section>
</section>
</section>

<section title="Request Header Fields" anchor="request.header.fields">
  <x:anchor-alias value="request-header"/>
<t>
   A client sends request header fields to provide more information about
   the request context, make the request conditional based on the target
   resource state, suggest preferred formats for the response, supply
   authentication credentials, or modify the expected request processing.
   These fields act as request modifiers, similar to the parameters on a
   programming language method invocation.
</t>
<section title="Controls" anchor="request.controls">
<t>
   Controls are request header fields that direct specific handling of the
   request.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>Cache-Control</c> <c><xref target="header.cache-control"/></c>
  <c>Expect</c> <c><xref target="header.expect"/></c>
  <c>Host</c> <c><xref target="header.host"/></c>
  <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c>
  <c>Pragma</c> <c><xref target="header.pragma"/></c>
  <c>TE</c> <c><xref target="header.te"/></c>
</texttable>

<section title="Expect" anchor="header.expect">
  <iref primary="true" item="Expect header field" x:for-anchor=""/>
  <iref primary="true" item="100-continue (expect value)"/>
  <x:anchor-alias value="Expect"/>
  <x:anchor-alias value="expectation"/>
  <x:anchor-alias value="100-continue"/>
<t>
   The "Expect" header field in a request indicates a certain set of
   behaviors (expectations) that need to be supported by the server in
   order to properly handle this request. The only such expectation defined
   by this specification is <x:ref>100-continue</x:ref>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/>
  <x:ref>Expect</x:ref>  = "100-continue"
</artwork></figure>
<t>
   The Expect field-value is case-insensitive.
</t>
<t>
   A server that receives an Expect field-value other than
   <x:ref>100-continue</x:ref> &MAY; respond with a
   <x:ref>417 (Expectation Failed)</x:ref> status code to indicate that the
   unexpected expectation cannot be met.
</t>
<t>
   A <x:dfn>100-continue</x:dfn> expectation informs recipients that the
   client is about to send a (presumably large) message body in this request
   and wishes to receive a <x:ref>100 (Continue)</x:ref> interim response if
   the request-line and header fields are not sufficient to cause an immediate
   success, redirect, or error response. This allows the client to wait for an
   indication that it is worthwhile to send the message body before actually
   doing so, which can improve efficiency when the message body is huge or
   when the client anticipates that an error is likely (e.g., when sending a
   state-changing method, for the first time, without previously verified
   authentication credentials).
</t>
<t>
   For example, a request that begins with
</t>
<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

</artwork></figure>
<t>
   allows the origin server to immediately respond with an error message, such
   as <x:ref>401 (Unauthorized)</x:ref> or <x:ref>405 (Method Not Allowed)</x:ref>,
   before the client starts filling the pipes with an unnecessary data
   transfer.
</t>
<t>
   Requirements for clients:
  <list style="symbols">
    <t>
     A client &MUST-NOT; generate a 100-continue expectation in a request that
     does not include a message body.
    </t>
    <t>
     A client that will wait for a <x:ref>100 (Continue)</x:ref> response
     before sending the request message body &MUST; send an
     <x:ref>Expect</x:ref> header field containing a 100-continue expectation.
    </t>
    <t>
     A client that sends a 100-continue expectation is not required to wait
     for any specific length of time; such a client &MAY; proceed to send the
     message body even if it has not yet received a response. Furthermore,
     since <x:ref>100 (Continue)</x:ref> responses cannot be sent through an
     HTTP/1.0 intermediary, such a client &SHOULD-NOT; wait for an indefinite
     period before sending the message body.
    </t>
    <t>
     A client that receives a <x:ref>417 (Expectation Failed)</x:ref> status
     code in response to a request containing a 100-continue expectation
     &SHOULD; repeat that request without a 100-continue expectation, since
     the 417 response merely indicates that the response chain does not
     support expectations (e.g., it passes through an HTTP/1.0 server).
    </t>
  </list>
</t>
<t>
   Requirements for servers:
  <list style="symbols">
    <t>
     A server that receives a 100-continue expectation in an HTTP/1.0 request
     &MUST; ignore that expectation.
    </t>
    <t>
     A server &MAY; omit sending a <x:ref>100 (Continue)</x:ref> response if
     it has already received some or all of the message body for the
     corresponding request, or if the framing indicates that there is no
     message body.
    </t>
    <t>
     A server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
     ultimately send a final status code, once the message body is received
     and processed, unless the connection is closed prematurely.
    </t>
    <t>
     A server that responds with a final status code before reading
     the entire message body &SHOULD; indicate in that response whether it
     intends to close the connection or continue reading and discarding the
     request message (see <xref target="persistent.tear-down"/>).
    </t>
  </list>
</t>
<t>
   An origin server &MUST;, upon receiving an HTTP/1.1 (or later) request-line
   and a complete header section that contains a 100-continue expectation and
   indicates a request message body will follow, either send an immediate
   response with a final status code, if that status can be determined by
   examining just the request-line and header fields, or send an immediate
   <x:ref>100 (Continue)</x:ref> response to encourage the client to send the
   request's message body. The origin server &MUST-NOT; wait for the message
   body before sending the <x:ref>100 (Continue)</x:ref> response.
</t>
<t>
   A proxy &MUST;, upon receiving an HTTP/1.1 (or later) request-line
   and a complete header section that contains a 100-continue expectation and
   indicates a request message body will follow, either send an immediate
   response with a final status code, if that status can be determined by
   examining just the request-line and header fields, or begin forwarding the
   request toward the origin server by sending a corresponding request-line
   and header section to the next inbound server. If the proxy believes (from
   configuration or past interaction) that the next inbound server only
   supports HTTP/1.0, the proxy &MAY; generate an immediate
   <x:ref>100 (Continue)</x:ref> response to encourage the client to begin
   sending the message body.
</t>
<aside>
  <t>
    &Note; The Expect header field was added after the original publication of
    HTTP/1.1 <xref target="RFC2068"/> as both the means to request an interim
    <x:ref>100 (Continue)</x:ref> response and the general mechanism for indicating must-understand
    extensions. However, the extension mechanism has not been used by clients
    and the must-understand requirements have not been implemented by many
    servers, rendering the extension mechanism useless. This specification has
    removed the extension mechanism in order to simplify the definition and
    processing of 100-continue.
  </t>
</aside>
</section>

<section title="Max-Forwards" anchor="header.max-forwards">
  <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>
  <x:anchor-alias value="Max-Forwards"/>
<t>
   The "Max-Forwards" header field provides a mechanism with the
   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
   request methods to limit the number of times that the request is forwarded by
   proxies. This can be useful when the client is attempting to
   trace a request that appears to be failing or looping mid-chain.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
  <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
</artwork></figure>
<t>
   The Max-Forwards value is a decimal integer indicating the remaining
   number of times this request message can be forwarded.
</t>
<t>
   Each intermediary that receives a TRACE or OPTIONS request containing a
   Max-Forwards header field &MUST; check and update its value prior to
   forwarding the request. If the received value is zero (0), the intermediary
   &MUST-NOT; forward the request; instead, the intermediary &MUST; respond as
   the final recipient. If the received Max-Forwards value is greater than
   zero, the intermediary &MUST; generate an updated Max-Forwards field in the
   forwarded message with a field-value that is the lesser of a) the received
   value decremented by one (1) or b) the recipient's maximum supported value
   for Max-Forwards.
</t>
<t>
   A recipient &MAY; ignore a Max-Forwards header field received with any
   other request methods.
</t>
</section>
</section>

<section title="Preconditions" anchor="preconditions">
  <iref item="conditional request" primary="true"/>
<t>
   A conditional request is an HTTP request with one or more request header
   fields that indicate a precondition to be tested before
   applying the request method to the target resource.
   <xref target="evaluation"/> defines when preconditions are applied.
   <xref target="precedence"/> defines the order of evaluation when more than
   one precondition is present.
</t>
<t>
   Conditional GET requests are the most efficient mechanism for HTTP
   cache updates <xref target="Caching"/>.  Conditionals can also be
   applied to state-changing methods, such as PUT and DELETE, to prevent
   the "lost update" problem: one client accidentally overwriting
   the work of another client that has been acting in parallel.
</t>
<t><iref primary="true" item="selected representation"/>
   Conditional request preconditions are based on the state of the target
   resource as a whole (its current value set) or the state as observed
   in a previously obtained representation (one value in that set).
   A resource might have multiple current representations, each with its
   own observable state.  The conditional request mechanisms assume that
   the mapping of requests to a "selected representation" (<xref target="representations"/>)
   will be consistent over time if the server intends to take advantage of
   conditionals. Regardless, if the mapping is inconsistent and the server is
   unable to select the appropriate representation, then no harm will result
   when the precondition evaluates to false.
</t>
<t>
   The following request header fields allow a
   client to place a precondition on the state of the target resource, so that
   the action corresponding to the method semantics will not be applied if the
   precondition evaluates to false. Each precondition defined by this
   specification consists of a comparison between a set of validators obtained
   from prior representations of the target resource to the current state of
   validators for the <x:ref>selected representation</x:ref>
   (<xref target="response.validator"/>). Hence, these preconditions evaluate
   whether the state of the target resource has changed since a given state
   known by the client. The effect of such an evaluation depends on the method
   semantics and choice of conditional, as defined in <xref target="evaluation"/>.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>If-Match</c> <c><xref target="header.if-match"/></c>
  <c>If-None-Match</c> <c><xref target="header.if-none-match"/></c>
  <c>If-Modified-Since</c> <c><xref target="header.if-modified-since"/></c>
  <c>If-Unmodified-Since</c> <c><xref target="header.if-unmodified-since"/></c>
  <c>If-Range</c> <c><xref target="header.if-range"/></c>
</texttable>

<section title="Evaluation" anchor="evaluation">
<t>
   Except when excluded below, a recipient cache or origin server &MUST;
   evaluate received request preconditions after it has successfully performed
   its normal request checks and just before it would perform the action
   associated with the request method.
   A server &MUST; ignore all received preconditions if its response to the
   same request without those conditions would have been a status code other
   than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>.
   In other words, redirects and failures take precedence over the evaluation
   of preconditions in conditional requests.
</t>
<t>
   A server that is not the origin server for the target resource and cannot
   act as a cache for requests on the target resource &MUST-NOT; evaluate the
   conditional request header fields defined by this specification, and it
   &MUST; forward them if the request is forwarded, since the generating
   client intends that they be evaluated by a server that can provide a
   current representation.
   Likewise, a server &MUST; ignore the conditional request header fields
   defined by this specification when received with a request method that does
   not involve the selection or modification of a
   <x:ref>selected representation</x:ref>, such as CONNECT, OPTIONS, or TRACE.
</t>
<t>
   Conditional request header fields that are defined by extensions to HTTP
   might place conditions on all recipients, on the state of the target
   resource in general, or on a group of resources. For instance, the "If"
   header field in WebDAV can make a request conditional on various aspects
   of multiple resources, such as locks, if the recipient understands and
   implements that field (<xref target="RFC4918" x:fmt="," x:sec="10.4"/>).
</t>
<t>
   Although conditional request header fields are defined as being usable with
   the HEAD method (to keep HEAD's semantics consistent with those of GET),
   there is no point in sending a conditional HEAD because a successful
   response is around the same size as a <x:ref>304 (Not Modified)</x:ref>
   response and more useful than a <x:ref>412 (Precondition Failed)</x:ref>
   response.
</t>
</section>

<section title="Precedence" anchor="precedence">
<t>
   When more than one conditional request header field is present in a request,
   the order in which the fields are evaluated becomes important. In practice,
   the fields defined in this document are consistently implemented in a
   single, logical order, since "lost update" preconditions have more strict
   requirements than cache validation, a validated cache is more efficient
   than a partial response, and entity tags are presumed to be more accurate
   than date validators.
</t>
<t>
   A recipient cache or origin server &MUST; evaluate the request
   preconditions defined by this specification in the following order:
   <list style="numbers">
     <t anchor="precedence1">When recipient is the origin server and
       <x:ref>If-Match</x:ref> is present,
       evaluate the <x:ref>If-Match</x:ref> precondition:
       <list style="symbols">
         <t>if true, continue to step <xref target="precedence3" format="counter"/></t>
         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref> unless
            it can be determined that the state-changing request has already
            succeeded (see <xref target="header.if-match"/>)</t>
       </list>
     </t>
     <t anchor="precedence2">When recipient is the origin server,
       <x:ref>If-Match</x:ref> is not present, and
       <x:ref>If-Unmodified-Since</x:ref> is present,
       evaluate the <x:ref>If-Unmodified-Since</x:ref> precondition:
       <list style="symbols">
         <t>if true, continue to step <xref target="precedence3" format="counter"/></t>
         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref> unless
            it can be determined that the state-changing request has already
            succeeded (see <xref target="header.if-unmodified-since"/>)</t>
       </list>
     </t>
     <t anchor="precedence3">When <x:ref>If-None-Match</x:ref> is present,
       evaluate the <x:ref>If-None-Match</x:ref> precondition:
       <list style="symbols">
         <t>if true, continue to step <xref target="precedence5" format="counter"/></t>
         <t>if false for GET/HEAD, respond <x:ref>304 (Not Modified)</x:ref></t>
         <t>if false for other methods, respond <x:ref>412 (Precondition Failed)</x:ref></t>
       </list>
     </t>
     <t anchor="precedence4">When the method is GET or HEAD,
       <x:ref>If-None-Match</x:ref> is not present, and
       <x:ref>If-Modified-Since</x:ref> is present,
       evaluate the <x:ref>If-Modified-Since</x:ref> precondition:
       <list style="symbols">
         <t>if true, continue to step <xref target="precedence5" format="counter"/></t>
         <t>if false, respond <x:ref>304 (Not Modified)</x:ref></t>
       </list>
     </t>
     <t anchor="precedence5">When the method is GET and both
       <x:ref>Range</x:ref> and <x:ref>If-Range</x:ref> are present,
       evaluate the <x:ref>If-Range</x:ref> precondition:
       <list style="symbols">
         <t>if the validator matches and the Range specification is
            applicable to the selected representation, respond
            <x:ref>206 (Partial Content)</x:ref></t>
       </list>
     </t>
     <t anchor="precedencelast">Otherwise,
       <list style="symbols">
         <t>all conditions are met, so perform the requested action and
            respond according to its success or failure.</t>
       </list>
     </t>
   </list>
</t>
<t>
   Any extension to HTTP/1.1 that defines additional conditional request
   header fields ought to define its own expectations regarding the order
   for evaluating such fields in relation to those defined in this document
   and other conditionals that might be found in practice.
</t>
</section>

<section title="If-Match" anchor="header.if-match">
  <iref primary="true" item="If-Match header field" x:for-anchor=""/>
  <x:anchor-alias value="If-Match"/>
<t>
   The "If-Match" header field makes the request method conditional on the
   recipient origin server either having at least one current
   representation of the target resource, when the field-value is "*", or
   having a current representation of the target resource that has an
   entity-tag matching a member of the list of entity-tags provided in the
   field-value.
</t>
<t>
   An origin server &MUST; use the strong comparison function when comparing
   entity-tags for If-Match (<xref target="entity.tag.comparison"/>), since
   the client intends this precondition to prevent the method from being
   applied if there have been any changes to the representation data.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
  <x:ref>If-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
</artwork></figure>
<t>
   Examples:
</t>
<figure><artwork type="example">
  If-Match: "xyzzy"
  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
  If-Match: *
</artwork></figure>
<t>
   If-Match is most often used with state-changing methods (e.g., POST, PUT,
   DELETE) to prevent accidental overwrites when multiple user agents might be
   acting in parallel on the same resource (i.e., to prevent the "lost update"
   problem). It can also be used with safe methods to abort a request if the
   <x:ref>selected representation</x:ref> does not match one already stored
   (or partially stored) from a prior request.
</t>
<t>
   An origin server that receives an If-Match header field &MUST; evaluate the
   condition prior to performing the method (<xref target="evaluation"/>).
   If the field-value is "*", the condition is false if the origin server
   does not have a current representation for the target resource.
   If the field-value is a list of entity-tags, the condition is false if
   none of the listed tags match the entity-tag of the selected representation.
</t>
<t>
   An origin server &MUST-NOT; perform the requested method if a received
   If-Match condition evaluates to false; instead, the origin server &MUST;
   respond with either
   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
   server has verified that a state change is being requested and the final
   state is already reflected in the current state of the target resource
   (i.e., the change requested by the user agent has already succeeded, but
   the user agent might not be aware of it, perhaps because the prior response
   was lost or a compatible change was made by some other user agent).
   In the latter case, the origin server &MUST-NOT; send a validator header
   field in the response unless it can verify that the request is a duplicate
   of an immediately prior change made by the same user agent.
</t>
<t>
   The If-Match header field can be ignored by caches and intermediaries
   because it is not applicable to a stored response.
</t>
</section>

<section title="If-None-Match" anchor="header.if-none-match">
  <iref primary="true" item="If-None-Match header field" x:for-anchor=""/>
  <x:anchor-alias value="If-None-Match"/>
<t>
   The "If-None-Match" header field makes the request method conditional on
   a recipient cache or origin server either not having any current
   representation of the target resource, when the field-value is "*", or
   having a selected representation with an entity-tag that does not match any
   of those listed in the field-value.
</t>
<t>
   A recipient &MUST; use the weak comparison function when comparing
   entity-tags for If-None-Match (<xref target="entity.tag.comparison"/>),
   since weak entity-tags can be used for cache validation even if there have
   been changes to the representation data.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
  <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
</artwork></figure>
<t>
   Examples:
</t>
<figure><artwork type="example">
  If-None-Match: "xyzzy"
  If-None-Match: W/"xyzzy"
  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
  If-None-Match: *
</artwork></figure>
<t>
   If-None-Match is primarily used in conditional GET requests to enable
   efficient updates of cached information with a minimum amount of
   transaction overhead. When a client desires to update one or more stored
   responses that have entity-tags, the client &SHOULD; generate an
   If-None-Match header field containing a list of those entity-tags when
   making a GET request; this allows recipient servers to send a
   <x:ref>304 (Not Modified)</x:ref> response to indicate when one of those
   stored responses matches the selected representation.
</t>
<t>
   If-None-Match can also be used with a value of "*" to prevent an unsafe
   request method (e.g., PUT) from inadvertently modifying an existing
   representation of the target resource when the client believes that
   the resource does not have a current representation (<xref target="safe.methods"/>).
   This is a variation on the "lost update" problem that might arise if more
   than one client attempts to create an initial representation for the target
   resource.
</t>
<t>
   An origin server that receives an If-None-Match header field &MUST;
   evaluate the condition prior to performing the method
   (<xref target="evaluation"/>).
   If the field-value is "*", the condition is false if the origin server
   has a current representation for the target resource.
   If the field-value is a list of entity-tags, the condition is false if
   one of the listed tags match the entity-tag of the selected representation.
</t>
<t>
   An origin server &MUST-NOT; perform the requested method if the condition
   evaluates to false; instead, the origin server &MUST; respond with either
   a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method
   is GET or HEAD or b) the <x:ref>412 (Precondition Failed)</x:ref> status
   code for all other request methods.
</t>
<t>
   Requirements on cache handling of a received If-None-Match header field
   are defined in <xref target="validation.received"/>.
</t>
</section>

<section title="If-Modified-Since" anchor="header.if-modified-since">
  <iref primary="true" item="If-Modified-Since header field" x:for-anchor=""/>
  <x:anchor-alias value="If-Modified-Since"/>
<t>
   The "If-Modified-Since" header field makes a GET or HEAD request method
   conditional on the selected representation's modification date being more
   recent than the date provided in the field-value. Transfer of the selected
   representation's data is avoided if that data has not changed.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
  <x:ref>If-Modified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
</artwork></figure>
<t>
   An example of the field is:
</t>
<figure><artwork type="example">
  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
</artwork></figure>
<t>
   A recipient &MUST; ignore If-Modified-Since if the request contains an
   <x:ref>If-None-Match</x:ref> header field; the condition in
   <x:ref>If-None-Match</x:ref> is considered to be a more accurate
   replacement for the condition in If-Modified-Since, and the two are only
   combined for the sake of interoperating with older intermediaries that
   might not implement <x:ref>If-None-Match</x:ref>.
</t>
<t>
   A recipient &MUST; ignore the If-Modified-Since header field if the
   received field-value is not a valid HTTP-date, or if the request method
   is neither GET nor HEAD.
</t>
<t>
   A recipient &MUST; interpret an If-Modified-Since field-value's timestamp
   in terms of the origin server's clock.
</t>
<t>
   If-Modified-Since is typically used for two distinct purposes:
   1) to allow efficient updates of a cached representation that does not
   have an entity-tag and 2) to limit the scope of a web traversal to resources 
   that have recently changed.
</t>
<t>
   When used for cache updates, a cache will typically use the value of the
   cached message's <x:ref>Last-Modified</x:ref> field to generate the field
   value of If-Modified-Since. This behavior is most interoperable for cases
   where clocks are poorly synchronized or when the server has chosen to only
   honor exact timestamp matches (due to a problem with Last-Modified dates
   that appear to go "back in time" when the origin server's clock is
   corrected or a representation is restored from an archived backup).
   However, caches occasionally generate the field value based on other data,
   such as the <x:ref>Date</x:ref> header field of the cached message or the
   local clock time that the message was received, particularly when the
   cached message does not contain a <x:ref>Last-Modified</x:ref> field.
</t>
<t>
   When used for limiting the scope of retrieval to a recent time window, a
   user agent will generate an If-Modified-Since field value based on either
   its own local clock or a <x:ref>Date</x:ref> header field received from the
   server in a prior response. Origin servers that choose an exact timestamp
   match based on the selected representation's <x:ref>Last-Modified</x:ref>
   field will not be able to help the user agent limit its data transfers to
   only those changed during the specified window.
</t>
<t>
   An origin server that receives an If-Modified-Since header field &SHOULD;
   evaluate the condition prior to performing the method
   (<xref target="evaluation"/>).
   The origin server &SHOULD-NOT; perform the requested method if the selected
   representation's last modification date is earlier than or equal to the
   date provided in the field-value; instead, the origin server &SHOULD;
   generate a <x:ref>304 (Not Modified)</x:ref> response, including only those
   metadata that are useful for identifying or updating a previously cached
   response.
</t>
<t>
   Requirements on cache handling of a received If-Modified-Since header field
   are defined in <xref target="validation.received"/>.
</t>
</section>

<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
  <iref primary="true" item="If-Unmodified-Since header field" x:for-anchor=""/>
  <x:anchor-alias value="If-Unmodified-Since"/>
<t>
   The "If-Unmodified-Since" header field makes the request method conditional
   on the selected representation's last modification date being earlier than or
   equal to the date provided in the field-value. This field accomplishes the
   same purpose as <x:ref>If-Match</x:ref> for cases where the user agent does
   not have an entity-tag for the representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
  <x:ref>If-Unmodified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
</artwork></figure>
<t>
   An example of the field is:
</t>
<figure><artwork type="example">
  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
</artwork></figure>
<t>
   A recipient &MUST; ignore If-Unmodified-Since if the request contains an
   <x:ref>If-Match</x:ref> header field; the condition in
   <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for
   the condition in If-Unmodified-Since, and the two are only combined for the
   sake of interoperating with older intermediaries that might not implement
   <x:ref>If-Match</x:ref>.
</t>
<t>
   A recipient &MUST; ignore the If-Unmodified-Since header field if the
   received field-value is not a valid HTTP-date.
</t>
<t>
   A recipient &MUST; interpret an If-Unmodified-Since field-value's timestamp
   in terms of the origin server's clock.
</t>
<t>
   If-Unmodified-Since is most often used with state-changing methods
   (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple
   user agents might be acting in parallel on a resource that does
   not supply entity-tags with its representations (i.e., to prevent the
   "lost update" problem). It can also be used with safe methods to abort a
   request if the <x:ref>selected representation</x:ref> does not match one
   already stored (or partially stored) from a prior request.
</t>
<t>
   An origin server that receives an If-Unmodified-Since header field &MUST;
   evaluate the condition prior to performing the method
   (<xref target="evaluation"/>).
   The origin server &MUST-NOT; perform the requested method if the selected
   representation's last modification date is more recent than the date
   provided in the field-value; instead the origin server &MUST; respond with either
   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
   server has verified that a state change is being requested and the final
   state is already reflected in the current state of the target resource
   (i.e., the change requested by the user agent has already succeeded, but
   the user agent might not be aware of that because the prior response message
   was lost or a compatible change was made by some other user agent).
   In the latter case, the origin server &MUST-NOT; send a validator header
   field in the response unless it can verify that the request is a duplicate
   of an immediately prior change made by the same user agent.
</t>
<t>
   The If-Unmodified-Since header field can be ignored by caches and
   intermediaries because it is not applicable to a stored response.
</t>
</section>

<section title="If-Range" anchor="header.if-range">
  <iref primary="true" item="If-Range header field" x:for-anchor=""/>
  <x:anchor-alias value="If-Range"/>
<t>
   The "If-Range" header field provides a special conditional request
   mechanism that is similar to the <x:ref>If-Match</x:ref> and
   <x:ref>If-Unmodified-Since</x:ref> header fields but that instructs the
   recipient to ignore the <x:ref>Range</x:ref> header field if the validator
   doesn't match, resulting in transfer of the new selected representation
   instead of a <x:ref>412 (Precondition Failed)</x:ref> response.
</t>
<t>
   If a client has a partial copy of a representation and wishes
   to have an up-to-date copy of the entire representation, it could use the
   <x:ref>Range</x:ref> header field with a conditional GET (using
   either or both of <x:ref>If-Unmodified-Since</x:ref> and
   <x:ref>If-Match</x:ref>.) However, if the precondition fails because the
   representation has been modified, the client would then have to make a
   second request to obtain the entire current representation.
</t>
<t>
   The "If-Range" header field allows a client to "short-circuit" the second
   request. Informally, its meaning is as follows: if the representation is unchanged,
   send me the part(s) that I am requesting in Range; otherwise, send me the
   entire representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
  <x:ref>If-Range</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref>
</artwork></figure>
<t>
   A client &MUST-NOT; generate an If-Range header field in a request that
   does not contain a <x:ref>Range</x:ref> header field.
   A server &MUST; ignore an If-Range header field received in a request that
   does not contain a <x:ref>Range</x:ref> header field.
   An origin server &MUST; ignore an If-Range header field received in a
   request for a target resource that does not support Range requests.
</t>
<t>
   A client &MUST-NOT; generate an If-Range header field containing an
   entity-tag that is marked as weak.
   A client &MUST-NOT; generate an If-Range header field containing an
   <x:ref>HTTP-date</x:ref> unless the client has no entity-tag for
   the corresponding representation and the date is a strong validator
   in the sense defined by <xref target="lastmod.comparison"/>.
</t>
<t>
   A server that evaluates an If-Range precondition &MUST; use the strong
   comparison function when comparing entity-tags (<xref target="entity.tag.comparison"/>)
   and &MUST; evaluate the condition as false if an <x:ref>HTTP-date</x:ref>
   validator is provided that is not a strong validator in the sense defined
   by <xref target="lastmod.comparison"/>.
   A valid <x:ref>entity-tag</x:ref> can be distinguished from a valid
   <x:ref>HTTP-date</x:ref> by examining the first two characters for a
   DQUOTE.
</t>
<t>
   If the validator given in the If-Range header field matches the current
   validator for the selected representation of the target resource, then
   the server &SHOULD; process the <x:ref>Range</x:ref> header field as
   requested. If the validator does not match, the server &MUST; ignore the
   <x:ref>Range</x:ref> header field. Note that this comparison by exact
   match, including when the validator is an <x:ref>HTTP-date</x:ref>, differs
   from the "earlier than or equal to" comparison used when evaluating an
   <x:ref>If-Unmodified-Since</x:ref> conditional.
</t>
</section>
</section>

<section title="Range" anchor="header.range">
  <iref primary="true" item="Range header field" x:for-anchor=""/>
  <x:anchor-alias value="Range"/>
  <x:anchor-alias value="other-ranges-specifier"/>
  <x:anchor-alias value="other-range-set"/>
<t>
   The "Range" header field on a GET request modifies the method semantics to
   request transfer of only one or more subranges of the selected
   representation data, rather than the entire selected representation data.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
  <x:ref>Range</x:ref> = <x:ref>byte-ranges-specifier</x:ref> / <x:ref>other-ranges-specifier</x:ref>
  <x:ref>other-ranges-specifier</x:ref> = <x:ref>other-range-unit</x:ref> "=" <x:ref>other-range-set</x:ref>
  <x:ref>other-range-set</x:ref> = 1*<x:ref>VCHAR</x:ref>
</artwork></figure>
<t>
   Clients often encounter interrupted data
   transfers as a result of canceled requests or dropped connections. When a
   client has stored a partial representation, it is desirable to request the
   remainder of that representation in a subsequent request rather than
   transfer the entire representation. Likewise, devices with limited local
   storage might benefit from being able to request only a subset of a larger
   representation, such as a single page of a very large document, or the
   dimensions of an embedded image.
</t>
<t>
   Range requests are an &OPTIONAL; feature
   of HTTP, designed so that recipients not implementing this feature (or not
   supporting it for the target resource) can respond as if it is a normal
   GET request without impacting interoperability. Partial responses are
   indicated by a distinct status code to not be mistaken for full responses
   by caches that might not implement the feature.
</t>
<t>
   A server &MAY; ignore the Range header field. However, origin servers and
   intermediate caches ought to support byte ranges when possible, since Range
   supports efficient recovery from partially failed transfers and partial
   retrieval of large representations. A server &MUST; ignore a Range header
   field received with a request method other than GET.
</t>
<t>
   Although the range request mechanism is designed to allow for
   extensible range types, this specification only defines requests for
   byte ranges.
</t>
<t>
   An origin server &MUST; ignore a Range header field that contains a range
   unit it does not understand. A proxy &MAY; discard a Range header
   field that contains a range unit it does not understand.
</t>
<t>
   A server that supports range requests &MAY; ignore or reject a
   <x:ref>Range</x:ref> header field that consists of more than two
   overlapping ranges, or a set of many small ranges that are not listed
   in ascending order, since both are indications of either a broken client or
   a deliberate denial-of-service attack (<xref target="overlapping.ranges"/>).
   A client &SHOULD-NOT; request multiple ranges that are inherently less
   efficient to process and transfer than a single range that encompasses the
   same data.
</t>
<t>
   A client that is requesting multiple ranges &SHOULD; list those ranges in
   ascending order (the order in which they would typically be received in a
   complete representation) unless there is a specific need to request a later
   part earlier. For example, a user agent processing a large representation
   with an internal catalog of parts might need to request later parts first,
   particularly if the representation consists of pages stored in reverse
   order and the user agent wishes to transfer one page at a time.
</t>
<t>
   The Range header field is evaluated after evaluating the precondition header
   fields defined in <xref target="preconditions"/>, and only if the result in absence
   of the Range header field would be a <x:ref>200 (OK)</x:ref> response. In
   other words, Range is ignored when a conditional GET would result in a
   <x:ref>304 (Not Modified)</x:ref> response.
</t>
<t>
   The If-Range header field (<xref target="header.if-range"/>) can be used as
   a precondition to applying the Range header field.
</t>
<t>
   If all of the preconditions are true, the server supports the Range header
   field for the target resource, and the specified range(s) are valid and
   satisfiable (as defined in <xref target="byte.ranges"/>), the
   server &SHOULD; send a <x:ref>206 (Partial Content)</x:ref> response with a
   payload containing one or more partial representations that correspond to
   the satisfiable ranges requested.
</t>
<t>
   If all of the preconditions are true, the server supports the Range header
   field for the target resource, and the specified range(s) are invalid or
   unsatisfiable, the server &SHOULD; send a
   <x:ref>416 (Range Not Satisfiable)</x:ref> response.
</t>
</section>

<section title="Content Negotiation" anchor="request.conneg">
<t>
   The following request header fields are sent by a user agent to engage in
   <x:ref>proactive negotiation</x:ref> of the response content, as defined in
   <xref target="proactive.negotiation"/>. The preferences sent in these
   fields apply to any content in the response, including representations of
   the target resource, representations of error or processing status, and
   potentially even the miscellaneous text strings that might appear within
   the protocol.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>Accept</c> <c><xref target="header.accept"/></c>
  <c>Accept-Charset</c> <c><xref target="header.accept-charset"/></c>
  <c>Accept-Encoding</c> <c><xref target="header.accept-encoding"/></c>
  <c>Accept-Language</c> <c><xref target="header.accept-language"/></c>
</texttable>

<section title="Quality Values" anchor="quality.values">
  <x:anchor-alias value="weight"/>
  <x:anchor-alias value="qvalue"/>
<t>
   Many of the request header fields for <x:ref>proactive negotiation</x:ref>
   use a common parameter, named "q" (case-insensitive), to assign a relative
   "weight" to the preference for that associated kind of content.
   This weight is referred to as a "quality value" (or "qvalue") because
   the same parameter name is often used within server configurations to
   assign a weight to the relative quality of the various representations
   that can be selected for a resource.
</t>
<t>
   The weight is normalized to a real number in the range 0 through 1,
   where 0.001 is the least preferred and 1 is the most preferred;
   a value of 0 means "not acceptable". If no "q" parameter is present,
   the default weight is 1.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="weight"/><iref primary="true" item="Grammar" subitem="qvalue"/>
  <x:ref>weight</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref>
  <x:ref>qvalue</x:ref> = ( "0" [ "." 0*3<x:ref>DIGIT</x:ref> ] )
         / ( "1" [ "." 0*3("0") ] )
</artwork></figure>
<t>
   A sender of qvalue &MUST-NOT; generate more than three digits after the
   decimal point. User configuration of these values ought to be limited in
   the same fashion.
</t>
</section>

<section title="Accept" anchor="header.accept">
  <iref primary="true" item="Accept header field" x:for-anchor=""/>
  <x:anchor-alias value="Accept"/>
  <x:anchor-alias value="accept-ext"/>
  <x:anchor-alias value="accept-params"/>
  <x:anchor-alias value="media-range"/>
<t>
   The "Accept" header field can be used by user agents to specify
   response media types that are acceptable. Accept header fields can be used to
   indicate that the request is specifically limited to a small set of desired
   types, as in the case of a request for an in-line image.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
  <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
  
  <x:ref>media-range</x:ref>    = ( "*/*"
                   / ( <x:ref>type</x:ref> "/" "*" )
                   / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
                   ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
  <x:ref>accept-params</x:ref>  = <x:ref>weight</x:ref> *( <x:ref>accept-ext</x:ref> )
  <x:ref>accept-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ]
</artwork></figure>
<t>
   The asterisk "*" character is used to group media types into ranges,
   with "*/*" indicating all media types and "type/*" indicating all
   subtypes of that type. The media-range can include media type
   parameters that are applicable to that range.
</t>
<t>
   Each media-range might be followed by zero or more applicable media type
   parameters (e.g., <x:ref>charset</x:ref>), an optional "q" parameter for
   indicating a relative weight (<xref target="quality.values"/>), and then zero or more extension
   parameters. The "q" parameter is necessary if any extensions (accept-ext) are present,
   since it acts as a separator between the two parameter sets.
</t>
<aside>
  <t>
    &Note; Use of the "q" parameter name to separate media type
    parameters from Accept extension parameters is due to historical
    practice. Although this prevents any media type parameter named
    "q" from being used with a media range, such an event is believed
    to be unlikely given the lack of any "q" parameters in the IANA
    media type registry and the rare usage of any media type
    parameters in Accept. Future media types are discouraged from
    registering any parameter named "q".
  </t>
</aside>
<t>
   The example
</t>
<figure><artwork type="example">
  Accept: audio/*; q=0.2, audio/basic
</artwork></figure>
<t>
   is interpreted as "I prefer audio/basic, but send me any audio
   type if it is the best available after an 80% markdown in quality".
</t>
<t>
   A request without any Accept header field implies that the user agent
   will accept any media type in response. If the header field is present in a
   request and none of the available representations for the response have a
   media type that is listed as acceptable, the origin server can either honor
   the header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
   or disregard the header field by treating the response as if it is not
   subject to content negotiation.
</t>
<t>
   A more elaborate example is
</t>
<figure><artwork type="example">
  Accept: text/plain; q=0.5, text/html,
          text/x-dvi; q=0.8, text/x-c
</artwork></figure>
<t>
   Verbally, this would be interpreted as "text/html and text/x-c are
   the equally preferred media types, but if they do not exist, then send the
   text/x-dvi representation, and if that does not exist, send the text/plain
   representation".
</t>
<t>
   Media ranges can be overridden by more specific media ranges or
   specific media types. If more than one media range applies to a given
   type, the most specific reference has precedence. For example,
</t>
<figure><artwork type="example">
  Accept: text/*, text/plain, text/plain;format=flowed, */*
</artwork></figure>
<t>
   have the following precedence:
   <list style="numbers">
    <t>text/plain;format=flowed</t>
    <t>text/plain</t>
    <t>text/*</t>
    <t>*/*</t>
   </list>
</t>
<t>
   The media type quality factor associated with a given type is
   determined by finding the media range with the highest precedence
   that matches the type. For example,
</t>
<figure><artwork type="example">
  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
          text/html;level=2;q=0.4, */*;q=0.5
</artwork></figure>
<t>
   would cause the following values to be associated:
</t>
<texttable align="left">
  <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
  <c>text/html;level=1</c>    <c>1</c>
  <c>text/html</c>            <c>0.7</c>
  <c>text/plain</c>           <c>0.3</c>
  <c>image/jpeg</c>           <c>0.5</c>
  <c>text/html;level=2</c>    <c>0.4</c>
  <c>text/html;level=3</c>    <c>0.7</c>
</texttable>
<t>
   &Note; A user agent might be provided with a default set of quality
   values for certain media ranges. However, unless the user agent is
   a closed system that cannot interact with other rendering agents,
   this default set ought to be configurable by the user.
</t>
</section>

<section title="Accept-Charset" anchor="header.accept-charset">
  <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
  <x:anchor-alias value="Accept-Charset"/>
<t>
   The "Accept-Charset" header field can be sent by a user agent to
   indicate what charsets are acceptable in textual response content.
   This field allows user agents capable of understanding more comprehensive
   or special-purpose charsets to signal that capability to an origin server
   that is capable of representing information in those charsets.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
  <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" ) [ <x:ref>weight</x:ref> ] )
</artwork></figure>
<t>
   Charset names are defined in <xref target="charset"/>.
   A user agent &MAY; associate a quality value with each charset to indicate
   the user's relative preference for that charset, as defined in <xref target="quality.values"/>.
   An example is
</t>
<figure><artwork type="example">
  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
</artwork></figure>
<t>
   The special value "*", if present in the Accept-Charset field,
   matches every charset that is not mentioned elsewhere in the
   Accept-Charset field. If no "*" is present in an Accept-Charset field,
   then any charsets not explicitly mentioned in the field are
   considered "not acceptable" to the client.
</t>
<t>
   A request without any Accept-Charset header field implies that the user
   agent will accept any charset in response. Most general-purpose user agents
   do not send Accept-Charset, unless specifically configured to do so, because
   a detailed list of supported charsets makes it easier for a server to
   identify an individual by virtue of the user agent's request characteristics
   (<xref target="fingerprinting"/>).
</t>
<t>
   If an Accept-Charset header field is present in a request and none of the
   available representations for the response has a charset that is listed as
   acceptable, the origin server can either honor the header field, by sending a
   <x:ref>406 (Not Acceptable)</x:ref> response, or disregard the header field by
   treating the resource as if it is not subject to content negotiation.
</t>
</section>

<section title="Accept-Encoding" anchor="header.accept-encoding">
  <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
  <x:anchor-alias value="Accept-Encoding"/>
  <x:anchor-alias value="codings"/>
<t>
   The "Accept-Encoding" header field can be used by user agents to
   indicate what response content-codings (<xref target="content.codings"/>)
   are acceptable in the response.  An "identity" token is used as a synonym
   for "no encoding" in order to communicate when no encoding is preferred.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
  <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>weight</x:ref> ] )
  <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
</artwork></figure>
<t>
   Each codings value &MAY; be given an associated quality value
   representing the preference for that encoding, as defined in <xref target="quality.values"/>.
   The asterisk "*" symbol in an Accept-Encoding field matches any available
   content-coding not explicitly listed in the header field.
</t>
<t>
   For example,
</t>
<figure><artwork type="example">
  Accept-Encoding: compress, gzip
  Accept-Encoding:
  Accept-Encoding: *
  Accept-Encoding: compress;q=0.5, gzip;q=1.0
  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
</artwork></figure>
<t>
   A request without an Accept-Encoding header field implies that the user
   agent has no preferences regarding content-codings. Although this allows
   the server to use any content-coding in a response, it does not imply that
   the user agent will be able to correctly process all encodings.
</t>
<t>
   A server tests whether a content-coding for a given representation is
   acceptable using these rules:
  <list style="numbers">
      <t>If no Accept-Encoding field is in the request, any content-coding is
         considered acceptable by the user agent.</t>

      <t>If the representation has no content-coding, then it is acceptable
         by default unless specifically excluded by the Accept-Encoding field
         stating either "identity;q=0" or "*;q=0" without a more specific
         entry for "identity".</t>

      <t>If the representation's content-coding is one of the content-codings
         listed in the Accept-Encoding field, then it is acceptable unless
         it is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
         qvalue of 0 means "not acceptable".)</t>

      <t>If multiple content-codings are acceptable, then the acceptable
         content-coding with the highest non-zero qvalue is preferred.</t>
  </list>
</t>
<t>
   An Accept-Encoding header field with a combined field-value that is empty
   implies that the user agent does not want any content-coding in response.
   If an Accept-Encoding header field is present in a request and none of the
   available representations for the response have a content-coding that
   is listed as acceptable, the origin server &SHOULD; send a response
   without any content-coding.
</t>
<aside>
  <t>
    &Note; Most HTTP/1.0 applications do not recognize or obey qvalues
    associated with content-codings. This means that qvalues might not
    work and are not permitted with x-gzip or x-compress.
  </t>
</aside>
</section>

<section title="Accept-Language" anchor="header.accept-language">
  <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
  <x:anchor-alias value="Accept-Language"/>
  <x:anchor-alias value="language-range"/>
<t>
   The "Accept-Language" header field can be used by user agents to
   indicate the set of natural languages that are preferred in the response.
   Language tags are defined in <xref target="language.tags"/>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
  <x:ref>Accept-Language</x:ref> = 1#( <x:ref>language-range</x:ref> [ <x:ref>weight</x:ref> ] )
  <x:ref>language-range</x:ref>  = 
            &lt;language-range, see <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
</artwork></figure>
<t>
   Each language-range can be given an associated quality value
   representing an estimate of the user's preference for the languages
   specified by that range, as defined in <xref target="quality.values"/>. For example,
</t>
<figure><artwork type="example">
  Accept-Language: da, en-gb;q=0.8, en;q=0.7
</artwork></figure>
<t>
   would mean: "I prefer Danish, but will accept British English and
   other types of English".
</t>
<t>
   A request without any Accept-Language header field implies that the user
   agent will accept any language in response. If the header field is present
   in a request and none of the available representations for the response have
   a matching language tag, the origin server can either disregard the header
   field by treating the response as if it is not subject to content
   negotiation or honor the header field by sending a <x:ref>406 (Not Acceptable)</x:ref>
   response. However, the latter is not encouraged, as doing so can prevent
   users from accessing content that they might be able to use (with
   translation software, for example). 
</t>
<t>
   Note that some recipients treat the order in which language tags are listed
   as an indication of descending priority, particularly for tags that are
   assigned equal quality values (no value is the same as q=1). However, this
   behavior cannot be relied upon. For consistency and to maximize
   interoperability, many user agents assign each language tag a unique
   quality value while also listing them in order of decreasing quality.
   Additional discussion of language priority lists can be found in
   <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>.
</t>
<t>
   For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines 
   several matching schemes. Implementations can offer the most appropriate
   matching scheme for their requirements. The "Basic Filtering" scheme
   (<xref target="RFC4647" x:fmt="," x:sec="3.3.1"/>) is identical to the
   matching scheme that was previously defined for HTTP in
   <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
</t>
<t>
   It might be contrary to the privacy expectations of the user to send
   an Accept-Language header field with the complete linguistic preferences of
   the user in every request (<xref target="fingerprinting"/>).
</t>
<t>
   Since intelligibility is highly dependent on the individual user, user
   agents need to allow user control over the linguistic preference (either
   through configuration of the user agent itself or by defaulting to a user
   controllable system setting).
   A user agent that does not provide such control to the user &MUST-NOT;
   send an Accept-Language header field.
</t>
<aside>
  <t>
    &Note; User agents ought to provide guidance to users when setting a
    preference, since users are rarely familiar with the details of language
    matching as described above. For example, users might assume that on
    selecting "en-gb", they will be served any kind of English document if
    British English is not available. A user agent might suggest, in such a
    case, to add "en" to the list for better matching behavior.
  </t>
</aside>
</section>
</section>

<section title="Authentication Credentials" anchor="request.auth">
<t>
   HTTP provides a general framework for access control and authentication,
   via an extensible set of challenge-response authentication schemes, which
   can be used by a server to challenge a client request and by a client to
   provide authentication information.
</t>
<t>
   Two header fields are used for carrying authentication credentials.
   Note that various custom mechanisms for
   user authentication use the Cookie header field for this purpose, as
   defined in <xref target="RFC6265"/>.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>Authorization</c> <c><xref target="header.authorization"/></c>
  <c>Proxy-Authorization</c> <c><xref target="header.proxy-authorization"/></c>
</texttable>

<section title="Challenge and Response" anchor="challenge.and.response">
  <x:anchor-alias value="auth-scheme"/>
  <x:anchor-alias value="auth-param"/>
  <x:anchor-alias value="token68"/>
  <x:anchor-alias value="challenge"/>
  <x:anchor-alias value="credentials"/>
<t>
   HTTP provides a simple challenge-response authentication framework
   that can be used by a server to challenge a client request and by a
   client to provide authentication information. It uses a case-insensitive
   token as a means to identify the authentication scheme, followed
   by additional information necessary for achieving authentication via that
   scheme. The latter can be either a comma-separated list of parameters or a
   single sequence of characters capable of holding base64-encoded
   information.
</t>
<t>
   Authentication parameters are name=value pairs, where the name token is
   matched case-insensitively,
   and each parameter name &MUST; only occur once per challenge.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="auth-scheme"/><iref primary="true" item="Grammar" subitem="auth-param"/><iref primary="true" item="Grammar" subitem="token68"/>
  auth-scheme    = <x:ref>token</x:ref>

  auth-param     = <x:ref>token</x:ref> <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> )

  token68        = 1*( <x:ref>ALPHA</x:ref> / <x:ref>DIGIT</x:ref> /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
</artwork></figure>
<t>
   The token68 syntax allows the 66 unreserved URI characters
   (<xref target="RFC3986"/>), plus a few others, so that it can hold a
   base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)
   encoding, with or without padding, but excluding whitespace
   (<xref target="RFC4648"/>).
</t>
<t>
   A <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin
   server to challenge the authorization of a user agent, including a
   <x:ref>WWW-Authenticate</x:ref> header field containing at least one
   challenge applicable to the requested resource.
</t>
<t>
   A <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
   used by a proxy to challenge the authorization of a client, including a
   <x:ref>Proxy-Authenticate</x:ref> header field containing at least one
   challenge applicable to the proxy for the requested resource.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/>
  <x:ref>challenge</x:ref>   = <x:ref>auth-scheme</x:ref> [ 1*<x:ref>SP</x:ref> ( <x:ref>token68</x:ref> / #<x:ref>auth-param</x:ref> ) ]
</artwork></figure>
<aside>
  <t>
     &Note; Many clients fail to parse a challenge that contains an unknown
     scheme. A workaround for this problem is to list well-supported schemes
     (such as "basic") first.<!-- see https://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
  </t>
</aside>
<t>
   A user agent that wishes to authenticate itself with an origin server
   &mdash; usually, but not necessarily, after receiving a
   <x:ref>401 (Unauthorized)</x:ref> &mdash; can do so by including an
   <x:ref>Authorization</x:ref> header field with the request.
</t>
<t>
   A client that wishes to authenticate itself with a proxy &mdash; usually,
   but not necessarily, after receiving a
   <x:ref>407 (Proxy Authentication Required)</x:ref> &mdash; can do so by
   including a <x:ref>Proxy-Authorization</x:ref> header field with the
   request.
</t>
<t>
   Both the <x:ref>Authorization</x:ref> field value and the
   <x:ref>Proxy-Authorization</x:ref> field value contain the client's
   credentials for the realm of the resource being requested, based upon a
   challenge received in a response (possibly at some point in the past).
   When creating their values, the user agent ought to do so by selecting the
   challenge with what it considers to be the most secure auth-scheme that it
   understands, obtaining credentials from the user as appropriate.
   Transmission of credentials within header field values implies significant
   security considerations regarding the confidentiality of the underlying
   connection, as described in
   <xref target="confidentiality.of.credentials"/>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="credentials"/>
  <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> [ 1*<x:ref>SP</x:ref> ( <x:ref>token68</x:ref> / #<x:ref>auth-param</x:ref> ) ]
</artwork></figure>
<t>
   Upon receipt of a request for a protected resource that omits credentials,
   contains invalid credentials (e.g., a bad password) or partial credentials
   (e.g., when the authentication scheme requires more than one round trip),
   an origin server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response
   that contains a <x:ref>WWW-Authenticate</x:ref> header field with at least
   one (possibly new) challenge applicable to the requested resource.
</t>
<t>
   Likewise, upon receipt of a request that omits proxy credentials or
   contains invalid or partial proxy credentials, a proxy that requires
   authentication &SHOULD; generate a
   <x:ref>407 (Proxy Authentication Required)</x:ref> response that contains
   a <x:ref>Proxy-Authenticate</x:ref> header field with at least one
   (possibly new) challenge applicable to the proxy.
</t>
<t>
   A server that receives valid credentials that are not adequate to gain
   access ought to respond with the <x:ref>403 (Forbidden)</x:ref> status
   code (<xref target="status.403"/>).
</t>
<t>
   HTTP does not restrict applications to this simple challenge-response
   framework for access authentication. Additional mechanisms can be used,
   such as authentication at the transport level or via message encapsulation,
   and with additional header fields specifying authentication information.
   However, such additional mechanisms are not defined by this specification.
</t>
</section>

<section title="Protection Space (Realm)" anchor="protection.space">
  <iref item="Protection Space"/>
  <iref item="Realm"/>
  <iref item="Canonical Root URI"/>
<t>
   The "<x:dfn>realm</x:dfn>" authentication parameter is reserved for use by
   authentication schemes that wish to indicate a scope of protection.
</t>
<t>
   A <x:dfn>protection space</x:dfn> is defined by the canonical root URI (the
   scheme and authority components of the effective request URI; see
   <xref target="effective.request.uri"/>) of the
   server being accessed, in combination with the realm value if present.
   These realms allow the protected resources on a server to be
   partitioned into a set of protection spaces, each with its own
   authentication scheme and/or authorization database. The realm value
   is a string, generally assigned by the origin server, that can have
   additional semantics specific to the authentication scheme. Note that a
   response can have multiple challenges with the same auth-scheme but
   with different realms.
</t>
<t>
   The protection space determines the domain over which credentials can
   be automatically applied. If a prior request has been authorized, the
   user agent &MAY; reuse the same credentials for all other requests within
   that protection space for a period of time determined by the authentication
   scheme, parameters, and/or user preferences (such as a configurable
   inactivity timeout). Unless specifically allowed by the authentication
   scheme, a single protection space cannot extend outside the scope of its
   server.
</t>
<t>
   For historical reasons, a sender &MUST; only generate the quoted-string syntax.
   Recipients might have to support both token and quoted-string syntax for
   maximum interoperability with existing clients that have been accepting both
   notations for a long time.
</t>
</section>

<section title="Authorization" anchor="header.authorization">
  <iref primary="true" item="Authorization header field" x:for-anchor=""/>
  <x:anchor-alias value="Authorization"/>
<t>
   The "Authorization" header field allows a user agent to authenticate itself
   with an origin server &mdash; usually, but not necessarily, after receiving
   a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
   credentials containing the authentication information of the user agent for
   the realm of the resource being requested.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
  <x:ref>Authorization</x:ref> = <x:ref>credentials</x:ref>
</artwork></figure>
<t>
   If a request is authenticated and a realm specified, the same credentials
   are presumed to be valid for all other requests within this realm (assuming
   that the authentication scheme itself does not require otherwise, such as
   credentials that vary according to a challenge value or using synchronized
   clocks).
</t>
<t>
   A proxy forwarding a request &MUST-NOT; modify any
   <x:ref>Authorization</x:ref> fields in that request.
   See <xref target="caching.authenticated.responses"/> for details of and requirements
   pertaining to handling of the Authorization field by HTTP caches.
</t>
</section>

<section title="Proxy-Authorization" anchor="header.proxy-authorization">
  <iref primary="true" item="Proxy-Authorization header field" x:for-anchor=""/>
  <x:anchor-alias value="Proxy-Authorization"/>
<t>
   The "Proxy-Authorization" header field allows the client to
   identify itself (or its user) to a proxy that requires
   authentication. Its value consists of credentials containing the
   authentication information of the client for the proxy and/or realm of the
   resource being requested.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
  <x:ref>Proxy-Authorization</x:ref> = <x:ref>credentials</x:ref>
</artwork></figure>
<t>
   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field
   applies only to the next inbound proxy that demanded authentication using
   the <x:ref>Proxy-Authenticate</x:ref> field. When multiple proxies are used
   in a chain, the Proxy-Authorization header field is consumed by the first
   inbound proxy that was expecting to receive credentials. A proxy &MAY;
   relay the credentials from the client request to the next proxy if that is
   the mechanism by which the proxies cooperatively authenticate a given
   request.
</t>
</section>

<section title="Authentication Scheme Extensibility" anchor="auth.scheme.extensibility">
<t>
   Aside from the general framework, this document does not specify any
   authentication schemes. New and existing authentication schemes are
   specified independently and ought to be registered within the
   "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry".
   For example, the "basic" and "digest" authentication schemes are defined by
   <xref target="RFC7617" x:fmt="none">RFC 7617</xref> and
   <xref target="RFC7616" x:fmt="none">RFC 7616</xref>, respectively.
</t>

<section title="Authentication Scheme Registry" anchor="auth.scheme.registry">
<t>
   The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
   defines the namespace for the authentication schemes in challenges and
   credentials. It is maintained
   at <eref target="https://www.iana.org/assignments/http-authschemes"/>.
</t>
<t>
  Registrations &MUST; include the following fields:
  <list style="symbols">
    <t>Authentication Scheme Name</t>
    <t>Pointer to specification text</t>
    <t>Notes (optional)</t>
  </list>
</t>
<t>
  Values to be added to this namespace require IETF Review
  (see <xref target="RFC8126" x:fmt="," x:sec="4.8"/>).
</t>
</section>

<section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.auth.schemes">
<t>
  There are certain aspects of the HTTP Authentication framework that put
  constraints on how new authentication schemes can work:
</t>
<ul>
  <li><t>
    HTTP authentication is presumed to be stateless: all of the information
    necessary to authenticate a request &MUST; be provided in the request,
    rather than be dependent on the server remembering prior requests.
    Authentication based on, or bound to, the underlying connection is
    outside the scope of this specification and inherently flawed unless
    steps are taken to ensure that the connection cannot be used by any
    party other than the authenticated user
    (see <xref target="intermediaries"/>).
  </t>
  </li>
  <li>
    <t>
      The authentication parameter "realm" is reserved for defining protection
      spaces as described in <xref target="protection.space"/>. New schemes
      &MUST-NOT; use it in a way incompatible with that definition.
    </t>
  </li>
  <li>
    <t>
      The "token68" notation was introduced for compatibility with existing
      authentication schemes and can only be used once per challenge or credential.
      Thus, new schemes ought to use the auth-param syntax instead, because
      otherwise future extensions will be impossible.
    </t>
  </li>
  <li>
    <t>
      The parsing of challenges and credentials is defined by this specification
      and cannot be modified by new authentication schemes. When the auth-param
      syntax is used, all parameters ought to support both token and
      quoted-string syntax, and syntactical constraints ought to be defined on
      the field value after parsing (i.e., quoted-string processing). This is
      necessary so that recipients can use a generic parser that applies to
      all authentication schemes.
    </t>
    <t>
      &Note; The fact that the value syntax for the "realm" parameter
      is restricted to quoted-string was a bad design choice not to be repeated
      for new parameters.
    </t>
  </li>
  <li>
    <t>
      Definitions of new schemes ought to define the treatment of unknown
      extension parameters. In general, a "must-ignore" rule is preferable
      to a "must-understand" rule, because otherwise it will be hard to introduce
      new parameters in the presence of legacy recipients. Furthermore,
      it's good to describe the policy for defining new parameters (such
      as "update the specification" or "use this registry").
    </t>
  </li>
  <li>
    <t>
      Authentication schemes need to document whether they are usable in
      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
    </t>
  </li>
  <li>
    <t>
      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
      the user agent and, therefore, have the same effect on HTTP caches as the
      "private" Cache-Control response directive (<xref target="cache-response-directive.private"/>),
      within the scope of the request in which they appear.
    </t>
    <t>
      Therefore, new authentication schemes that choose not to carry
      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
      header field) will need to explicitly disallow caching, by mandating the use of
      either Cache-Control request directives (e.g., "no-store",
      <xref target="cache-request-directive.no-store"/>) or response directives (e.g., "private").
    </t>
  </li>
</ul>
</section>
</section>
</section>

<section title="Request Context" anchor="request.context">
<t>
   The following request header fields provide additional information about the
   request context, including information about the user, user agent, and
   resource behind the request.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>From</c> <c><xref target="header.from"/></c>
  <c>Referer</c> <c><xref target="header.referer"/></c>
  <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
</texttable>

<section title="From" anchor="header.from">
  <iref primary="true" item="From header field" x:for-anchor=""/>
  <x:anchor-alias value="From"/>
  <x:anchor-alias value="mailbox"/>
<t>
   The "From" header field contains an Internet email address for a human
   user who controls the requesting user agent. The address ought to be
   machine-usable, as defined by "mailbox"
   in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>:
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
  <x:ref>From</x:ref>    = <x:ref>mailbox</x:ref>
  
  <x:ref>mailbox</x:ref> = &lt;mailbox, see <xref x:sec="3.4" x:fmt="," target="RFC5322"/>&gt;
</artwork></figure>
<t>
   An example is:
</t>
<figure><artwork type="example">
  From: webmaster@example.org
</artwork></figure>
<t>
   The From header field is rarely sent by non-robotic user agents.
   A user agent &SHOULD-NOT; send a From header field without explicit
   configuration by the user, since that might conflict with the user's
   privacy interests or their site's security policy.
</t>
<t>
   A robotic user agent &SHOULD; send a valid From header field so that the
   person responsible for running the robot can be contacted if problems
   occur on servers, such as if the robot is sending excessive, unwanted,
   or invalid requests.
</t>
<t>
   A server &SHOULD-NOT; use the From header field for access control or
   authentication, since most recipients will assume that the field value is
   public information.
</t>
</section>

<section title="Referer" anchor="header.referer">
  <iref primary="true" item="Referer header field" x:for-anchor=""/>
  <x:anchor-alias value="Referer"/>
<t>
   The "Referer" [sic] header field allows the user agent to specify a URI
   reference for the resource from which the <x:ref>target URI</x:ref> was
   obtained (i.e., the "referrer", though the field name is misspelled).
   A user agent &MUST-NOT; include the fragment and userinfo components
   of the URI reference <xref target="RFC3986"/>, if any, when generating the
   Referer field value.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
  <x:ref>Referer</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
</artwork></figure>
<t>
   The Referer header field allows servers to generate back-links to other
   resources for simple analytics, logging, optimized caching, etc. It also
   allows obsolete or mistyped links to be found for maintenance. Some servers
   use the Referer header field as a means of denying links from other sites
   (so-called "deep linking") or restricting cross-site request forgery (CSRF),
   but not all requests contain it.
</t>
<t>
   Example:
</t>
<figure><artwork type="example">
  Referer: http://www.example.org/hypertext/Overview.html
</artwork></figure>
<t>
   If the target URI was obtained from a source that does not have its own
   URI (e.g., input from the user keyboard, or an entry within the user's
   bookmarks/favorites), the user agent &MUST; either exclude the Referer field
   or send it with a value of "about:blank".
</t>
<t>
   The Referer field has the potential to reveal information about the request
   context or browsing history of the user, which is a privacy concern if the
   referring resource's identifier reveals personal information (such as an
   account name) or a resource that is supposed to be confidential (such as
   behind a firewall or internal to a secured service). Most general-purpose
   user agents do not send the Referer header field when the referring
   resource is a local "file" or "data" URI. A user agent &MUST-NOT; send a
   <x:ref>Referer</x:ref> header field in an unsecured HTTP request if the
   referring page was received with a secure protocol.
   See <xref target="sensitive.information.in.uris"/> for additional
   security considerations.
</t>
<t>
   Some intermediaries have been known to indiscriminately remove Referer
   header fields from outgoing requests. This has the unfortunate side effect
   of interfering with protection against CSRF attacks, which can be far
   more harmful to their users. Intermediaries and user agent extensions that
   wish to limit information disclosure in Referer ought to restrict their
   changes to specific edits, such as replacing internal domain names with
   pseudonyms or truncating the query and/or path components.
   An intermediary &SHOULD-NOT; modify or delete the Referer header field when
   the field value shares the same scheme and host as the request target.
</t>
</section>

<section title="User-Agent" anchor="header.user-agent">
  <iref primary="true" item="User-Agent header field" x:for-anchor=""/>
  <x:anchor-alias value="User-Agent"/>
  <x:anchor-alias value="product"/>
  <x:anchor-alias value="product-version"/>
<t>
   The "User-Agent" header field contains information about the user agent
   originating the request, which is often used by servers to help identify
   the scope of reported interoperability problems, to work around or tailor
   responses to avoid particular user agent limitations, and for analytics
   regarding browser or operating system use. A user agent &SHOULD; send
   a User-Agent field in each request unless specifically configured not
   to do so.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/>
  <x:ref>User-Agent</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
</artwork></figure>
<t>
   The User-Agent field-value consists of one or more product identifiers,
   each followed by zero or more comments (<xref target="header.fields"/>), which together
   identify the user agent software and its significant subproducts.
   By convention, the product identifiers are listed in decreasing order of
   their significance for identifying the user agent software. Each product
   identifier consists of a name and optional version.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
  <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
  <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t>
   A sender &SHOULD; limit generated product identifiers to what is necessary
   to identify the product; a sender &MUST-NOT; generate advertising or other
   nonessential information within the product identifier.
   A sender &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
   that is not a version identifier (i.e., successive versions of the same
   product name ought to differ only in the product-version portion of the
   product identifier).
</t>
<t>
   Example:
</t>
<figure><artwork type="example">
  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
</artwork></figure>
<t>
   A user agent &SHOULD-NOT; generate a User-Agent field containing needlessly
   fine-grained detail and &SHOULD; limit the addition of subproducts by third
   parties. Overly long and detailed User-Agent field values increase request
   latency and the risk of a user being identified against their wishes
   ("fingerprinting").
</t>
<t>
   Likewise, implementations are encouraged not to use the product tokens of
   other implementations in order to declare compatibility with them, as this
   circumvents the purpose of the field. If a user agent masquerades as a
   different user agent, recipients can assume that the user intentionally
   desires to see responses tailored for that identified user agent, even
   if they might not work as well for the actual user agent being used.
</t>
</section>
</section>
</section>

<section title="Response Status Codes" anchor="status.codes">
<t>
   The status-code element is a three-digit integer code giving the result of the
   attempt to understand and satisfy the request.
</t>
<t>
   HTTP status codes are extensible. HTTP clients are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, a client &MUST;
   understand the class of any status code, as indicated by the first
   digit, and treat an unrecognized status code as being equivalent to the
   x00 status code of that class, with the exception that
   a recipient &MUST-NOT; cache a response with an unrecognized status code.
</t>
<t>
   For example, if an unrecognized status code of 471 is received by a client,
   the client can assume that there was something wrong with its request and
   treat the response as if it had received a <x:ref>400 (Bad Request)</x:ref> status code. The response
   message will usually contain a representation that explains the status.
</t>
<t>
   The first digit of the status-code defines the class of response. The
   last two digits do not have any categorization role. There are five
   values for the first digit:
  <list style="symbols">
    <t>
      <x:ref>1xx (Informational)</x:ref>: The request was received, continuing
      process
    </t>
    <t>
      <x:ref>2xx (Successful)</x:ref>: The request was successfully received,
      understood, and accepted
    </t>
    <t>
      <x:ref>3xx (Redirection)</x:ref>: Further action needs to be taken in order to
      complete the request
    </t>
    <t>
      <x:ref>4xx (Client Error)</x:ref>: The request contains bad syntax or cannot
      be fulfilled
    </t>
    <t>
      <x:ref>5xx (Server Error)</x:ref>: The server failed to fulfill an apparently
      valid request
    </t>
  </list>
</t>

<section title="Overview of Status Codes" anchor="overview.of.status.codes">
<t>  
   The status codes listed below are defined in this specification.
   The reason phrases listed here are only recommendations &mdash; they can be
   replaced by local equivalents without affecting the protocol.
</t>
<t>
   Responses with status codes that are defined as cacheable by default
   (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this
   specification) can be reused by a cache with heuristic expiration unless
   otherwise indicated by the method definition or explicit cache controls
   <xref target="Caching"/>; all other status codes are not cacheable by default.
</t>
<?BEGININC build/draft-ietf-httpbis-semantics-latest.iana-status-codes ?>
<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
<texttable align="left"
           suppress-title="true"
           anchor="iana.status.code.registration.table">
   <ttcol>Value</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Reference</ttcol>
   <c>100</c>
   <c>Continue</c>
   <c>
      <xref target="status.100"/>
   </c>
   <c>101</c>
   <c>Switching Protocols</c>
   <c>
      <xref target="status.101"/>
   </c>
   <c>200</c>
   <c>OK</c>
   <c>
      <xref target="status.200"/>
   </c>
   <c>201</c>
   <c>Created</c>
   <c>
      <xref target="status.201"/>
   </c>
   <c>202</c>
   <c>Accepted</c>
   <c>
      <xref target="status.202"/>
   </c>
   <c>203</c>
   <c>Non-Authoritative Information</c>
   <c>
      <xref target="status.203"/>
   </c>
   <c>204</c>
   <c>No Content</c>
   <c>
      <xref target="status.204"/>
   </c>
   <c>205</c>
   <c>Reset Content</c>
   <c>
      <xref target="status.205"/>
   </c>
   <c>206</c>
   <c>Partial Content</c>
   <c>
      <xref target="status.206"/>
   </c>
   <c>300</c>
   <c>Multiple Choices</c>
   <c>
      <xref target="status.300"/>
   </c>
   <c>301</c>
   <c>Moved Permanently</c>
   <c>
      <xref target="status.301"/>
   </c>
   <c>302</c>
   <c>Found</c>
   <c>
      <xref target="status.302"/>
   </c>
   <c>303</c>
   <c>See Other</c>
   <c>
      <xref target="status.303"/>
   </c>
   <c>304</c>
   <c>Not Modified</c>
   <c>
      <xref target="status.304"/>
   </c>
   <c>305</c>
   <c>Use Proxy</c>
   <c>
      <xref target="status.305"/>
   </c>
   <c>306</c>
   <c>(Unused)</c>
   <c>
      <xref target="status.306"/>
   </c>
   <c>307</c>
   <c>Temporary Redirect</c>
   <c>
      <xref target="status.307"/>
   </c>
   <c>400</c>
   <c>Bad Request</c>
   <c>
      <xref target="status.400"/>
   </c>
   <c>401</c>
   <c>Unauthorized</c>
   <c>
      <xref target="status.401"/>
   </c>
   <c>402</c>
   <c>Payment Required</c>
   <c>
      <xref target="status.402"/>
   </c>
   <c>403</c>
   <c>Forbidden</c>
   <c>
      <xref target="status.403"/>
   </c>
   <c>404</c>
   <c>Not Found</c>
   <c>
      <xref target="status.404"/>
   </c>
   <c>405</c>
   <c>Method Not Allowed</c>
   <c>
      <xref target="status.405"/>
   </c>
   <c>406</c>
   <c>Not Acceptable</c>
   <c>
      <xref target="status.406"/>
   </c>
   <c>407</c>
   <c>Proxy Authentication Required</c>
   <c>
      <xref target="status.407"/>
   </c>
   <c>408</c>
   <c>Request Timeout</c>
   <c>
      <xref target="status.408"/>
   </c>
   <c>409</c>
   <c>Conflict</c>
   <c>
      <xref target="status.409"/>
   </c>
   <c>410</c>
   <c>Gone</c>
   <c>
      <xref target="status.410"/>
   </c>
   <c>411</c>
   <c>Length Required</c>
   <c>
      <xref target="status.411"/>
   </c>
   <c>412</c>
   <c>Precondition Failed</c>
   <c>
      <xref target="status.412"/>
   </c>
   <c>413</c>
   <c>Payload Too Large</c>
   <c>
      <xref target="status.413"/>
   </c>
   <c>414</c>
   <c>URI Too Long</c>
   <c>
      <xref target="status.414"/>
   </c>
   <c>415</c>
   <c>Unsupported Media Type</c>
   <c>
      <xref target="status.415"/>
   </c>
   <c>416</c>
   <c>Range Not Satisfiable</c>
   <c>
      <xref target="status.416"/>
   </c>
   <c>417</c>
   <c>Expectation Failed</c>
   <c>
      <xref target="status.417"/>
   </c>
   <c>426</c>
   <c>Upgrade Required</c>
   <c>
      <xref target="status.426"/>
   </c>
   <c>500</c>
   <c>Internal Server Error</c>
   <c>
      <xref target="status.500"/>
   </c>
   <c>501</c>
   <c>Not Implemented</c>
   <c>
      <xref target="status.501"/>
   </c>
   <c>502</c>
   <c>Bad Gateway</c>
   <c>
      <xref target="status.502"/>
   </c>
   <c>503</c>
   <c>Service Unavailable</c>
   <c>
      <xref target="status.503"/>
   </c>
   <c>504</c>
   <c>Gateway Timeout</c>
   <c>
      <xref target="status.504"/>
   </c>
   <c>505</c>
   <c>HTTP Version Not Supported</c>
   <c>
      <xref target="status.505"/>
   </c>
</texttable>
<!--(END)-->

<?ENDINC build/draft-ietf-httpbis-semantics-latest.iana-status-codes ?>
<t>
   Note that this list is not exhaustive &mdash; it does not include
   extension status codes defined in other specifications
   (<xref target="status.code.extensibility"/>).
</t>
</section>

<section title="Informational 1xx" anchor="status.1xx">
  <x:anchor-alias value="1xx"/>
  <x:anchor-alias value="1xx (Informational)"/>
  <iref primary="true" item="1xx Informational (status code class)" x:for-anchor=""/>
  <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/>
<t>
   The <x:dfn>1xx (Informational)</x:dfn> class of status code indicates an
   interim response for communicating connection status or request progress
   prior to completing the requested action and sending a final response.
   1xx responses are terminated by the first empty line after the
   status-line (the empty line signaling the end of the header section).
   Since HTTP/1.0 did not define any 1xx status codes, a server &MUST-NOT; send
   a 1xx response to an HTTP/1.0 client.
</t>
<t>
   A client &MUST; be able to parse one or more 1xx responses received
   prior to a final response, even if the client does not expect one.
   A user agent &MAY; ignore unexpected 1xx responses.
</t>
<t>
   A proxy &MUST; forward 1xx responses unless the proxy itself
   requested the generation of the 1xx response. For example, if a
   proxy adds an "Expect: 100-continue" field when it forwards a request,
   then it need not forward the corresponding <x:ref>100 (Continue)</x:ref>
   response(s).
</t>

<section title="100 Continue" anchor="status.100">
  <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/>
  <x:anchor-alias value="100 (Continue)"/>
<t>
   The <x:dfn>100 (Continue)</x:dfn> status code indicates that the initial
   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
   been fully received and acted upon.
</t>
<t>
   When the request contains an <x:ref>Expect</x:ref> header field that
   includes a <x:ref>100-continue</x:ref> expectation, the 100 response
   indicates that the server wishes to receive the request payload body,
   as described in <xref target="header.expect"/>.  The client
   ought to continue sending the request and discard the 100 response.
</t>
<t>
   If the request did not contain an <x:ref>Expect</x:ref> header field
   containing the <x:ref>100-continue</x:ref> expectation,
   the client can simply discard this interim response.
</t>
</section>

<section title="101 Switching Protocols" anchor="status.101">
  <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/>
  <x:anchor-alias value="101 (Switching Protocols)"/>
<t>
   The <x:dfn>101 (Switching Protocols)</x:dfn> status code indicates that the
   server understands and is willing to comply with the client's request,
   via the <x:ref>Upgrade</x:ref> header field (<xref target="header.upgrade"/>), for
   a change in the application protocol being used on this connection.
   The server &MUST; generate an Upgrade header field in the response that
   indicates which protocol(s) will be switched to immediately after the empty
   line that terminates the 101 response.
</t>
<t>
   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
   HTTP might be advantageous over older versions, and switching to a
   real-time, synchronous protocol might be advantageous when delivering
   resources that use such features.
</t>
</section>
</section>

<section title="Successful 2xx" anchor="status.2xx">
  <x:anchor-alias value="2xx"/>
  <x:anchor-alias value="2xx (Successful)"/>
  <iref primary="true" item="2xx Successful (status code class)" x:for-anchor=""/>
  <iref primary="true" item="Status Codes Classes" subitem="2xx Successful" x:for-anchor=""/>
<t>
   The <x:dfn>2xx (Successful)</x:dfn> class of status code indicates that
   the client's request was successfully received, understood, and accepted.
</t>

<section title="200 OK" anchor="status.200">
  <iref primary="true" item="200 OK (status code)" x:for-anchor=""/>
  <x:anchor-alias value="200 (OK)"/>
<t>
   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
   succeeded. The payload sent in a 200 response depends on the request
   method. For the methods defined by this specification, the intended meaning
   of the payload can be summarized as:
  <list style="hanging">
    <t hangText="GET">
      a representation of the <x:ref>target resource</x:ref>;
    </t>
    <t hangText="HEAD">
      the same representation as GET, but without the representation data;
    </t>
    <t hangText="POST">
      a representation of the status of, or results obtained from, the action;
    </t>
    <t hangText="PUT, DELETE">
      a representation of the status of the action;
    </t>
    <t hangText="OPTIONS">
      a representation of the communications options;
    </t>
    <t hangText="TRACE">
      a representation of the request message as received by the
      end server.
    </t>
  </list>
</t>
<t>
   Aside from responses to CONNECT, a 200 response always has a payload,
   though an origin server &MAY; generate a payload body of zero length.
   If no payload is desired, an origin server ought to send
   <x:dfn>204 (No Content)</x:dfn> instead.
   For CONNECT, no payload is allowed because the successful result is a
   tunnel, which begins immediately after the 200 response header section.
</t>
<t>
   A 200 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="201 Created" anchor="status.201">
  <iref primary="true" item="201 Created (status code)" x:for-anchor=""/>
  <x:anchor-alias value="201 (Created)"/>
<t>
   The <x:dfn>201 (Created)</x:dfn> status code indicates that the request has
   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
   <x:ref>Location</x:ref> header field in the response or, if no
   <x:ref>Location</x:ref> field is received, by the effective request URI.
</t>
<t>
   The 201 response payload typically describes and links to the resource(s)
   created. See <xref target="response.validator"/> for a discussion of the
   meaning and purpose of validator header fields, such as
   <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>, in a 201 response.
</t>
</section>

<section title="202 Accepted" anchor="status.202">
  <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/>
  <x:anchor-alias value="202 (Accepted)"/>
<t>
   The <x:dfn>202 (Accepted)</x:dfn> status code indicates that the request
   has been accepted for processing, but the processing has not been
   completed. The request might or might not eventually be acted upon, as it
   might be disallowed when processing actually takes place. There is no
   facility in HTTP for re-sending a status code from an asynchronous
   operation.
</t>
<t>
   The 202 response is intentionally noncommittal. Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed. The representation sent with this
   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
   when the request will be fulfilled.
</t>
</section>

<section title="203 Non-Authoritative Information" anchor="status.203">
  <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/>
  <x:anchor-alias value="203 (Non-Authoritative Information)"/>
<t>
   The <x:dfn>203 (Non-Authoritative Information)</x:dfn> status code
   indicates that the request was successful but the enclosed payload has been
   modified from that of the origin server's <x:ref>200 (OK)</x:ref> response
   by a transforming proxy (<xref target="message.transformations"/>). This status code allows the
   proxy to notify recipients when a transformation has been applied, since
   that knowledge might impact later decisions regarding the content. For
   example, future cache validation requests for the content might only be
   applicable along the same request path (through the same proxies).
</t>
<t>
   The 203 response is similar to the Warning code of 214 Transformation
   Applied (<xref target="header.warning"/>), which has the advantage of being applicable
   to responses with any status code.
</t>
<t>
   A 203 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="204 No Content" anchor="status.204">
  <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/>
  <x:anchor-alias value="204 (No Content)"/>
<t>
   The <x:dfn>204 (No Content)</x:dfn> status code indicates that the server
   has successfully fulfilled the request and that there is no additional
   content to send in the response payload body. Metadata in the response
   header fields refer to the <x:ref>target resource</x:ref> and its
   <x:ref>selected representation</x:ref> after the requested action was applied.
</t>
<t>
   For example, if a 204 status code is received in response to a PUT
   request and the response contains an <x:ref>ETag</x:ref> header field, then
   the PUT was successful and the ETag field-value contains the entity-tag for
   the new representation of that target resource.
</t>
<t>
   The 204 response allows a server to indicate that the action has been
   successfully applied to the target resource, while implying that the
   user agent does not need to traverse away from its current "document view"
   (if any).  The server assumes that the user agent will provide some
   indication of the success to its user, in accord with its own interface,
   and apply any new or updated metadata in the response to its active
   representation.
</t>
<t>
   For example, a 204 status code is commonly used with document editing
   interfaces corresponding to a "save" action, such that the document
   being saved remains available to the user for editing. It is also
   frequently used with interfaces that expect automated data transfers
   to be prevalent, such as within distributed version control systems.
</t>
<t>
   A 204 response is terminated by the first empty line after the header
   fields because it cannot contain a message body.
</t>
<t>
   A 204 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="205 Reset Content" anchor="status.205">
  <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/>
<t>
   The <x:dfn>205 (Reset Content)</x:dfn> status code indicates that 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
   as received from the origin server.
</t>
<t>   
   This response is intended to support a common data entry use case where
   the user receives content that supports data entry (a form, notepad,
   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
   reset for the next entry so that the user can easily initiate another
   input action.
</t>
<t>
   Since the 205 status code implies that no additional content will be
   provided, a server &MUST-NOT; generate a payload in a 205 response.
   In other words, a server &MUST; do one of the following for a 205 response:
   a) indicate a zero-length body for the response by including a
   <x:ref>Content-Length</x:ref> header field with a value of 0;
   b) indicate a zero-length payload for the response by including a
   <x:ref>Transfer-Encoding</x:ref> header field with a value of chunked and
   a message body consisting of a single chunk of zero-length; or,
   c) close the connection immediately after sending the blank line
   terminating the header section.
</t>
</section>

<section title="206 Partial Content" anchor="status.206">
  <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
  <x:anchor-alias value="206"/>
  <x:anchor-alias value="206 (Partial Content)"/>
<t>
   The <x:dfn>206 (Partial Content)</x:dfn> status code indicates that the
   server is successfully fulfilling a range request for the target resource
   by transferring one or more parts of the selected representation that
   correspond to the satisfiable ranges found in the request's
   <x:ref>Range</x:ref> header field (<xref target="header.range"/>).
</t>
<t>
   When a 206 response is generated, the server &MUST; generate the following
   header fields, in addition to those required in the subsections below, if the field would
   have been sent in a <x:ref>200 (OK)</x:ref> response to the same request:
   <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
   <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref>, and
   <x:ref>Vary</x:ref>.
</t>
<t>
   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
   header field, the sender &SHOULD-NOT; generate other representation header
   fields beyond those required, because the client is understood to
   already have a prior response containing those header fields.
   Otherwise, the sender &MUST; generate all of the representation header
   fields that would have been sent in a <x:ref>200 (OK)</x:ref> response
   to the same request.
</t>
<t>
   A 206 response is cacheable by default; i.e., unless otherwise indicated by
   explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>

<section title="Single Part" anchor="partial.single">
<t>
   If a single part is being transferred, the server generating the 206
   response &MUST; generate a <x:ref>Content-Range</x:ref> header field,
   describing what range of the selected representation is enclosed, and a
   payload consisting of the range. For example:
</t>
<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...
</artwork></figure>
</section>

<section title="Multiple Parts" anchor="partial.multipart">
<t>
   If multiple parts are being transferred, the server generating the 206
   response &MUST; generate a "multipart/byteranges" payload, as defined
   in <xref target="multipart.byteranges"/>, and a
   <x:ref>Content-Type</x:ref> header field containing the
   multipart/byteranges media type and its required boundary parameter.
   To avoid confusion with single-part responses, a server &MUST-NOT; generate
   a <x:ref>Content-Range</x:ref> header field in the HTTP header section of a
   multiple part response (this field will be sent in each part instead).
</t>
<t>
   Within the header area of each body part in the multipart payload, the
   server &MUST; generate a <x:ref>Content-Range</x:ref> header field
   corresponding to the range being enclosed in that body part.
   If the selected representation would have had a <x:ref>Content-Type</x:ref>
   header field in a <x:ref>200 (OK)</x:ref> response, the server &SHOULD;
   generate that same <x:ref>Content-Type</x:ref> field in the header area of
   each body part. For example:
</t>
<figure><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--
</artwork></figure>
<t>
   When multiple ranges are requested, a server &MAY; coalesce any of 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
   corresponding byte-range-spec appeared in the received <x:ref>Range</x:ref>
   header field. Since the typical overhead between parts of a
   multipart/byteranges payload is around 80 bytes, depending on the selected
   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
   transfer the entire selected representation.
</t>
<t>
   A server &MUST-NOT; generate a multipart response to a request for a single
   range, since a client that does not request multiple parts might not
   support multipart responses. However, a server &MAY; generate a
   multipart/byteranges payload with only a single body part if multiple
   ranges were requested and only one range was found to be satisfiable or
   only one range remained after coalescing.
   A client that cannot process a multipart/byteranges response &MUST-NOT; 
   generate a request that asks for multiple ranges.
</t>
<t>
   When a multipart response payload is generated, the server &SHOULD; send
   the parts in the same order that the corresponding byte-range-spec appeared
   in the received <x:ref>Range</x:ref> header field, excluding those ranges
   that were deemed unsatisfiable or that were coalesced into other ranges.
   A client that receives a multipart response &MUST; inspect the
   <x:ref>Content-Range</x:ref> header field present in each body part in
   order to determine which range is contained in that body part; a client
   cannot rely on receiving the same ranges that it requested, nor the same
   order that it requested.
</t>
</section>

<section title="Combining Parts" anchor="combining.byte.ranges">
<t>
   A response might transfer only a subrange of a representation if the
   connection closed prematurely or if the request used one or more Range
   specifications.  After several such transfers, a client might have
   received several ranges of the same representation.  These ranges can only
   be safely combined if they all have in common the same strong validator
   (<xref target="weak.and.strong.validators"/>).
</t>
<t>
   A client that has received multiple partial responses to GET requests on a
   target resource &MAY; combine those responses into a larger continuous
   range if they share the same strong validator.
</t>
<t>
   If the most recent response is an incomplete <x:ref>200 (OK)</x:ref>
   response, then the header fields of that response are used for any
   combined response and replace those of the matching stored responses.
</t>
<t>
   If the most recent response is a <x:ref>206 (Partial Content)</x:ref>
   response and at least one of the matching stored responses is a
   <x:ref>200 (OK)</x:ref>, then the combined response header fields consist
   of the most recent 200 response's header fields. If all of the matching
   stored responses are 206 responses, then the stored response with the most
   recent header fields is used as the source of header fields for the
   combined response, except that the client &MUST; use other header fields
   provided in the new response, aside from <x:ref>Content-Range</x:ref>, to
   replace all instances of the corresponding header fields in the stored
   response.
</t>
<t>
   The combined response message body consists of the union of partial
   content ranges in the new response and each of the selected responses.
   If the union consists of the entire range of the representation, then the
   client &MUST; process the combined response as if it were a complete
   <x:ref>200 (OK)</x:ref> response, including a <x:ref>Content-Length</x:ref>
   header field that reflects the complete length.
   Otherwise, the client &MUST; process the set of continuous ranges as one of
   the following:
   an incomplete <x:ref>200 (OK)</x:ref> response if the combined response is
   a prefix of the representation,
   a single <x:ref>206 (Partial Content)</x:ref> response containing a
   multipart/byteranges body, or
   multiple <x:ref>206 (Partial Content)</x:ref> responses, each with one
   continuous range that is indicated by a <x:ref>Content-Range</x:ref> header
   field.
</t>
</section>
</section>
</section>

<section title="Redirection 3xx" anchor="status.3xx">
  <x:anchor-alias value="3xx"/>
  <x:anchor-alias value="3xx (Redirection)"/>
  <iref primary="true" item="3xx Redirection (status code class)" x:for-anchor=""/>
  <iref primary="true" item="Status Codes Classes" subitem="3xx Redirection" x:for-anchor=""/>
<t>
   The <x:dfn>3xx (Redirection)</x:dfn> class of status code indicates that
   further action needs to be taken by the user agent in order to fulfill the
   request. If a <x:ref>Location</x:ref> header field
   (<xref target="header.location"/>) is provided, the user agent &MAY;
   automatically redirect its request to the URI referenced by the Location
   field value, even if the specific status code is not understood.
   Automatic redirection needs to done with care for methods not known to be
   <x:ref>safe</x:ref>, as defined in <xref target="safe.methods"/>, since
   the user might not wish to redirect an unsafe request.
</t>
<t>
   There are several types of redirects:
</t>
<ol>
  <li>
    <t>
      Redirects that indicate the resource might be available at a
      different URI, as provided by the <x:ref>Location</x:ref> field,
      as in the status codes <x:ref>301 (Moved Permanently)</x:ref>,
      <x:ref>302 (Found)</x:ref>, and
      <x:ref>307 (Temporary Redirect)</x:ref>.
    </t>
  </li>
  <li>
    <t>
      Redirection that offers a choice of matching resources, each capable
      of representing the original request target, as in the
      <x:ref>300 (Multiple Choices)</x:ref> status code.
    </t>
  </li>
  <li>
    <t>
      Redirection to a different resource, identified by the
      <x:ref>Location</x:ref> field, that can represent an indirect
      response to the request, as in the <x:ref>303 (See Other)</x:ref>
      status code.
    </t>
  </li>
  <li>
    <t>
      Redirection to a previously cached result, as in the
      <x:ref>304 (Not Modified)</x:ref> status code.
    </t>
  </li>
</ol>
<aside>
  <t>
    &Note; In HTTP/1.0, the status codes <x:ref>301 (Moved Permanently)</x:ref>
    and <x:ref>302 (Found)</x:ref> were defined for the first type of redirect
    (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>). Early user agents split
    on whether the method applied to the redirect target would be the same as
    the original request or would be rewritten as GET. Although HTTP
    originally defined the former semantics for <x:ref>301</x:ref> and
    <x:ref>302</x:ref> (to match its original implementation at CERN), and
    defined <x:ref>303 (See Other)</x:ref> to match the latter semantics,
    prevailing practice gradually converged on the latter semantics for
    <x:ref>301</x:ref> and <x:ref>302</x:ref> as well. The first revision of
    HTTP/1.1 added <x:ref>307 (Temporary Redirect)</x:ref> to indicate the
    former semantics without being impacted by divergent practice.
    Over 10 years later, most user agents still do method rewriting for
    <x:ref>301</x:ref> and <x:ref>302</x:ref>; therefore, this specification
    makes that behavior conformant when the original request is POST.
  </t>
</aside>
<t>
   A client &SHOULD; detect and intervene in cyclical redirections (i.e.,
   "infinite" redirection loops).
</t>
<aside>
  <t>
    &Note; An earlier version of this specification recommended a
    maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>).
    Content developers need to be aware that some clients might
    implement such a fixed limitation.
  </t>
</aside>

<section title="300 Multiple Choices" anchor="status.300">
  <iref primary="true" item="300 Multiple Choices (status code)" x:for-anchor=""/>
  <x:anchor-alias value="300 (Multiple Choices)"/>
<t>
   The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the
   <x:ref>target resource</x:ref> has more than one representation, each with
   its own more specific identifier, and information about the alternatives is
   being provided so that the user (or user agent) can select a preferred
   representation by redirecting its request to one or more of those
   identifiers. In other words, the server desires that the user agent engage
   in reactive negotiation to select the most appropriate representation(s)
   for its needs (<xref target="content.negotiation"/>).
</t>
<t>
   If the server has a preferred choice, the server &SHOULD; generate a
   <x:ref>Location</x:ref> header field containing a preferred choice's URI
   reference. The user agent &MAY; use the Location field value for automatic
   redirection.
</t>
<t>
   For request methods other than HEAD, the server &SHOULD; generate a payload
   in the 300 response containing a list of representation metadata and URI
   reference(s) from which the user or user agent can choose the one most
   preferred. The user agent &MAY; make a selection from that list
   automatically if it understands the provided media type. A specific format
   for automatic selection is not defined by this specification because HTTP
   tries to remain orthogonal to the definition of its payloads.
   In practice, the representation is provided in some easily parsed format
   believed to be acceptable to the user agent, as determined by shared design
   or content negotiation, or in some commonly accepted hypertext format.
</t>
<t>
   A 300 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
<aside>
  <t>
   &Note; The original proposal for the 300 status code defined the URI header field as
   providing a list of alternative representations, such that it would be
   usable for 200, 300, and 406 responses and be transferred in responses to
   the HEAD method. However, lack of deployment and disagreement over syntax
   led to both URI and Alternates (a subsequent proposal) being dropped from
   this specification. It is possible to communicate the list using a set of
   Link header fields <xref target="RFC5988"/>, each with a relationship of
   "alternate", though deployment is a chicken-and-egg problem.
  </t>
</aside>
</section>

<section title="301 Moved Permanently" anchor="status.301">
  <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/>
  <x:anchor-alias value="301"/>
  <x:anchor-alias value="301 (Moved Permanently)"/>
<t>
   The <x:dfn>301 (Moved Permanently)</x:dfn> status code indicates that the
   <x:ref>target resource</x:ref> has been assigned a new permanent URI and
   any future references to this resource ought to use one of the enclosed
   URIs. Clients with link-editing capabilities ought to automatically re-link
   references to the effective request URI to one or more of the new
   references sent by the server, where possible.
</t>
<t>
   The server &SHOULD; generate a <x:ref>Location</x:ref> header field in the
   response containing a preferred URI reference for the new permanent URI.
   The user agent &MAY; use the Location field value for automatic redirection.
   The server's response payload usually contains a short hypertext note with
   a hyperlink to the new URI(s).
</t>
<aside>
  <t>
    &Note; For historical reasons, a user agent &MAY; change the
    request method from POST to GET for the subsequent request. If this
    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
    status code can be used instead.
  </t>
</aside>
<t>
   A 301 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="302 Found" anchor="status.302">
  <iref primary="true" item="302 Found (status code)" x:for-anchor=""/>
  <x:anchor-alias value="302"/>
  <x:anchor-alias value="302 (Found)"/>
<t>
   The <x:dfn>302 (Found)</x:dfn> status code indicates that the target
   resource resides temporarily under a different URI. Since the redirection
   might be altered on occasion, the client ought to continue to use the
   effective request URI for future requests.
</t>
<t>
   The server &SHOULD; generate a <x:ref>Location</x:ref> header field in the
   response containing a URI reference for the different URI.
   The user agent &MAY; use the Location field value for automatic redirection.
   The server's response payload usually contains a short hypertext note with
   a hyperlink to the different URI(s).
</t>
<aside>
  <t>
    &Note; For historical reasons, a user agent &MAY; change the
    request method from POST to GET for the subsequent request. If this
    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
    status code can be used instead.
  </t>
</aside>
</section>

<section title="303 See Other" anchor="status.303">
  <iref primary="true" item="303 See Other (status code)" x:for-anchor=""/>
  <x:anchor-alias value="303 (See Other)"/>
<t>
   The <x:dfn>303 (See Other)</x:dfn> status code indicates that the server is
   redirecting the user agent to a different resource, as indicated by a URI
   in the <x:ref>Location</x:ref> header field, which is intended to provide
   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),
   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
   header field is not considered equivalent to the effective request URI.
</t>
<t>
   This status code is applicable to any HTTP method.  It is
   primarily used to allow the output of a POST action to redirect
   the user agent to a selected resource, since doing so provides the
   information corresponding to the POST response in a form that
   can be separately identified, bookmarked, and cached, independent
   of the original request.
</t>
<t>
   A 303 response to a GET request indicates that the origin server does not
   have a representation of the <x:ref>target resource</x:ref> that can be
   transferred by the server over HTTP. However, the
   <x:ref>Location</x:ref> field value refers to a resource that is
   descriptive of the target resource, such that making a retrieval request
   on that other resource might result in a representation that is useful to
   recipients without implying that it represents the original target resource.
   Note that answers to the questions of what can be represented, what
   representations are adequate, and what might be a useful description are
   outside the scope of HTTP.
</t>
<t>
   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
   same URI reference provided in the <x:ref>Location</x:ref> header field.
</t>
</section>

<section title="304 Not Modified" anchor="status.304">
  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
  <x:anchor-alias value="304"/>
  <x:anchor-alias value="304 (Not Modified)"/>
<t>
   The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a
   conditional GET or HEAD request has been
   received and would have resulted in a <x:ref>200 (OK)</x:ref> response
   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
   representation of the target resource because the request indicates that
   the client, which made the request conditional, already has a valid
   representation; the server is therefore redirecting the client to make
   use of that stored representation as if it were the payload of a
   <x:ref>200 (OK)</x:ref> response.
</t>
<t>
   The server generating a 304 response &MUST; generate any of the following
   header fields that would have been sent in a <x:ref>200 (OK)</x:ref>
   response to the same request:
   <x:ref>Cache-Control</x:ref>,
   <x:ref>Content-Location</x:ref>,
   <x:ref>Date</x:ref>,
   <x:ref>ETag</x:ref>,
   <x:ref>Expires</x:ref>, and
   <x:ref>Vary</x:ref>.
</t>
<t>
   Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations,
   a sender &SHOULD-NOT; generate representation metadata other
   than the above listed fields unless said metadata exists for the
   purpose of guiding cache updates (e.g., <x:ref>Last-Modified</x:ref> might
   be useful if the response does not have an <x:ref>ETag</x:ref> field).
</t>
<t>
   Requirements on a cache that receives a 304 response are defined in
   <xref target="freshening.responses"/>. If the conditional request originated with an
   outbound client, such as a user agent with its own cache sending a
   conditional GET to a shared proxy, then the proxy &SHOULD; forward the
   304 response to that client.
</t>
<t>
   A 304 response cannot contain a message-body; it is always
   terminated by the first empty line after the header fields.
</t>
</section>

<section title="305 Use Proxy" anchor="status.305">
  <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/>
  <x:anchor-alias value="305 (Use Proxy)"/>
<t>
   The <x:dfn>305 (Use Proxy)</x:dfn> status code was defined in a previous
   version of this specification and is now deprecated (<xref target="RFC7231" x:fmt="of" x:sec="B"/>).
</t>
</section>

<section title="306 (Unused)" anchor="status.306">
  <iref primary="true" item="306 (Unused) (status code)" x:for-anchor=""/>
<t>
   The 306 status code was defined in a previous version of this
   specification, is no longer used, and the code is reserved.
</t>
</section>

<section title="307 Temporary Redirect" anchor="status.307">
  <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/>
  <x:anchor-alias value="307"/>
  <x:anchor-alias value="307 (Temporary Redirect)"/>
<t>
   The <x:dfn>307 (Temporary Redirect)</x:dfn> status code indicates that the
   <x:ref>target resource</x:ref> resides temporarily under a different URI
   and the user agent &MUST-NOT; change the request method if it performs an
   automatic redirection to that URI.
   Since the redirection can change over time, the client ought to continue
   using the original effective request URI for future requests.
</t>
<t>
   The server &SHOULD; generate a <x:ref>Location</x:ref> header field in the
   response containing a URI reference for the different URI.
   The user agent &MAY; use the Location field value for automatic redirection.
   The server's response payload usually contains a short hypertext note with
   a hyperlink to the different URI(s).
</t>
<aside>
  <t>
    &Note; This status code is similar to <x:ref>302 (Found)</x:ref>, except
    that it does not allow changing the request method from POST to GET. This
    specification defines no equivalent counterpart for <x:ref>301 (Moved
    Permanently)</x:ref> (<xref target="RFC7238"/>,
    however, defines the status code 308 (Permanent Redirect) for this purpose). 
  </t>
</aside>
</section>
</section>

<section title="Client Error 4xx" anchor="status.4xx">
  <x:anchor-alias value="4xx"/>
  <x:anchor-alias value="4xx (Client Error)"/>
  <iref primary="true" item="4xx Client Error (status code class)" x:for-anchor=""/>
  <iref primary="true" item="Status Codes Classes" subitem="4xx Client Error" x:for-anchor=""/>
<t>
   The <x:dfn>4xx (Client Error)</x:dfn> class of status code indicates that
   the client seems to have erred. Except when responding to a HEAD request,
   the server &SHOULD; send a representation containing an explanation of
   the error situation, and whether it is a temporary or permanent condition.
   These status codes are applicable to any request method. User agents
   &SHOULD; display any included representation to the user.
</t>

<section title="400 Bad Request" anchor="status.400">
  <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/>
  <x:anchor-alias value="400 (Bad Request)"/>
<t>
   The <x:dfn>400 (Bad Request)</x:dfn> status code indicates that the server
   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
   message framing, or deceptive request routing).
</t>
</section>

<section title="401 Unauthorized" anchor="status.401">
  <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
  <x:anchor-alias value="401 (Unauthorized)"/>
<t>
   The <x:dfn>401 (Unauthorized)</x:dfn> status code indicates that the
   request has not been applied because it lacks valid authentication
   credentials for the target resource.
   The server generating a 401 response &MUST; send a
   <x:ref>WWW-Authenticate</x:ref> header field
   (<xref target="header.www-authenticate"/>)
   containing at least one challenge applicable to the target resource.
</t>
<t>
   If the request included authentication credentials, then the 401 response
   indicates that authorization has been refused for those credentials.
   The user agent &MAY; repeat the request with a new or replaced
   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
   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
   user agent &SHOULD; present the enclosed representation to the user, since
   it usually contains relevant diagnostic information.
</t>
</section>

<section title="402 Payment Required" anchor="status.402">
  <iref primary="true" item="402 Payment Required (status code)" x:for-anchor=""/>
  <x:anchor-alias value="402 (Payment Required)"/>
<t>
   The <x:dfn>402 (Payment Required)</x:dfn> status code is reserved for
   future use.
</t>
</section>

<section title="403 Forbidden" anchor="status.403">
  <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/>
  <x:anchor-alias value="403 (Forbidden)"/>
<t>
   The <x:dfn>403 (Forbidden)</x:dfn> status code indicates that the
   server understood the request but refuses to authorize it.
   A server that wishes to make public why the request has been forbidden
   can describe that reason in the response payload (if any).
</t>
<t>
   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.
   The client &SHOULD-NOT; automatically repeat the request with the same
   credentials.
   The client &MAY; repeat the request with new or different credentials.
   However, a request might be forbidden for reasons unrelated to the
   credentials.
</t>
<t>
   An origin server that wishes to "hide" the current existence of a forbidden
   <x:ref>target resource</x:ref> &MAY; instead respond with a status
   code of <x:ref>404 (Not Found)</x:ref>.
</t>
</section>

<section title="404 Not Found" anchor="status.404">
  <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/>
  <x:anchor-alias value="404 (Not Found)"/>
<t>
   The <x:dfn>404 (Not Found)</x:dfn> status code indicates that the origin
   server did not find a current representation for the
   <x:ref>target resource</x:ref> or is not willing to disclose that one
   exists. A 404 status code does not indicate whether this lack of representation
   is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is
   preferred over 404 if the origin server knows, presumably through some
   configurable means, that the condition is likely to be permanent.
</t>
<t>
   A 404 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="405 Method Not Allowed" anchor="status.405">
  <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/>
  <x:anchor-alias value="405 (Method Not Allowed)"/>
<t>
   The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the
   method received in the request-line is known by the origin server but
   not supported by the <x:ref>target resource</x:ref>.
   The origin server &MUST; generate an <x:ref>Allow</x:ref> header field in
   a 405 response containing a list of the target resource's currently
   supported methods.
</t>
<t>
   A 405 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>

</section>

<section title="406 Not Acceptable" anchor="status.406">
  <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/>
  <x:anchor-alias value="406 (Not Acceptable)"/>
<t>
   The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the
   <x:ref>target resource</x:ref> does not have a current representation that
   would be acceptable to the user agent, according to the
   <x:ref>proactive negotiation</x:ref> header fields received in the request
   (<xref target="request.conneg"/>), and the server is unwilling to supply a
   default representation.
</t>
<t>
   The server &SHOULD; generate a payload containing a list of available
   representation characteristics and corresponding resource identifiers from
   which the user or user agent can choose the one most appropriate.
   A user agent &MAY; automatically select the most appropriate choice from
   that list. However, this specification does not define any standard for
   such automatic selection, as described in <xref target="status.300"/>.
</t>
</section>

<section title="407 Proxy Authentication Required" anchor="status.407">
  <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
  <x:anchor-alias value="407 (Proxy Authentication Required)"/>
<t>
   The <x:dfn>407 (Proxy Authentication Required)</x:dfn> status code is
   similar to <x:ref>401 (Unauthorized)</x:ref>, but it indicates that the client
   needs to authenticate itself in order to use a proxy.
   The proxy &MUST; send a <x:ref>Proxy-Authenticate</x:ref> header field
   (<xref target="header.proxy-authenticate"/>) containing a challenge
   applicable to that proxy for the target resource. The client &MAY; repeat
   the request with a new or replaced <x:ref>Proxy-Authorization</x:ref>
   header field (<xref target="header.proxy-authorization"/>).
</t>
</section>

<section title="408 Request Timeout" anchor="status.408">
  <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/>
  <x:anchor-alias value="408 (Request Timeout)"/>
<t>
   The <x:dfn>408 (Request Timeout)</x:dfn> status code indicates
   that the server did not receive a complete request message within the time
   that it was prepared to wait.
   A server &SHOULD; send the "<x:ref>close</x:ref>" connection option
   (<xref target="header.connection"/>) in the response, since 408 implies that the server
   has decided to close the connection rather than continue waiting.
   If the client has an outstanding request in transit,
   the client &MAY; repeat that request on a new connection.
</t>
</section>

<section title="409 Conflict" anchor="status.409">
  <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/>
  <x:anchor-alias value="409 (Conflict)"/>
<t>
   The <x:dfn>409 (Conflict)</x:dfn> status code indicates that the request
   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
   resolve the conflict and resubmit the request. The server &SHOULD; generate
   a payload that includes enough information for a user to recognize the
   source of the conflict.
</t>
<t>
   Conflicts are most likely to occur in response to a PUT request. For
   example, if versioning were being used and the representation being PUT
   included changes to a resource that conflict with those made by an
   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
   representation would likely contain information useful for merging the
   differences based on the revision history.
</t>
</section>

<section title="410 Gone" anchor="status.410">
  <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/>
  <x:anchor-alias value="410 (Gone)"/>
<t>
   The <x:dfn>410 (Gone)</x:dfn> status code indicates that access to the
   <x:ref>target resource</x:ref> is no longer available at 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
   condition is permanent, the status code <x:ref>404 (Not Found)</x:ref>
   ought to be used instead.
</t>
<t>
   The 410 response is primarily intended to assist the task of web
   maintenance by notifying the recipient that the resource is
   intentionally unavailable and that the server owners desire that
   remote links to that resource be removed. Such an event is common for
   limited-time, promotional services and for resources belonging to
   individuals no longer associated with the origin server's site. It is not
   necessary to mark all permanently unavailable resources as "gone" or
   to keep the mark for any length of time &mdash; that is left to the
   discretion of the server owner.
</t>
<t>
   A 410 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>
</section>

<section title="411 Length Required" anchor="status.411">
  <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/>
  <x:anchor-alias value="411 (Length Required)"/>
<t>
   The <x:dfn>411 (Length Required)</x:dfn> status code indicates that the
   server refuses to accept the request without a defined
   <x:ref>Content-Length</x:ref> (<xref target="header.content-length"/>).
   The client &MAY; repeat the request if it adds a valid Content-Length
   header field containing the length of the message body in the request
   message.
</t>
</section>

<section title="412 Precondition Failed" anchor="status.412">
  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
  <x:anchor-alias value="412 (Precondition Failed)"/>
<t>
   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
   or more conditions given in the request header fields evaluated to false
   when tested on the server. This response code allows the client to place
   preconditions on the current resource state (its current representations
   and metadata) and, thus, prevent the request method from being applied if the
   target resource is in an unexpected state.
</t>
</section>

<section title="413 Payload Too Large" anchor="status.413">
  <iref primary="true" item="413 Payload Too Large (status code)" x:for-anchor=""/>
  <x:anchor-alias value="413 (Payload Too Large)"/>
<t>
   The <x:dfn>413 (Payload Too Large)</x:dfn> status code indicates
   that the server is refusing to process a request because the request
   payload is larger than the server is willing or able to process.
   The server &MAY; close the connection to prevent the client from continuing
   the request.
</t>
<t>
   If the condition is temporary, the server &SHOULD; generate a
   <x:ref>Retry-After</x:ref> header field to indicate that it is temporary
   and after what time the client &MAY; try again.
</t>
</section>

<section title="414 URI Too Long" anchor="status.414">
  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
  <x:anchor-alias value="414 (URI Too Long)"/>
<t>
   The <x:dfn>414 (URI Too Long)</x:dfn> status code indicates that the server
   is refusing to service the request because the
   request-target (<xref target="request.target"/>) is longer than the server is willing to
   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
   information, when the client has descended into a "black hole" 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
   exploit potential security holes.
</t>
<t>
   A 414 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>

</section>

<section title="415 Unsupported Media Type" anchor="status.415">
  <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/>
  <x:anchor-alias value="415 (Unsupported Media Type)"/>
<t>
   The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that
   the origin server is refusing to service the request because the payload is
   in a format not supported by this method on the <x:ref>target resource</x:ref>.
   The format problem might be due to the request's indicated
   <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a
   result of inspecting the data directly.
</t>
</section>

<section title="416 Range Not Satisfiable" anchor="status.416">
  <iref primary="true" item="416 Range Not Satisfiable (status code)" x:for-anchor=""/>
  <x:anchor-alias value="416 (Range Not Satisfiable)"/>
<t>
   The <x:dfn>416 (Range Not Satisfiable)</x:dfn> status code indicates that
   none of the ranges in the request's <x:ref>Range</x:ref> header field
   (<xref target="header.range"/>) overlap the current extent of the selected
   resource or that the set of ranges requested has been rejected due to
   invalid ranges or an excessive request of small or overlapping ranges.
</t>
<t>
   For byte ranges, failing to overlap the current extent means that the
   <x:ref>first-byte-pos</x:ref> of all of the <x:ref>byte-range-spec</x:ref>
   values were greater than the current length of the selected representation.
   When this status code is generated in response to a byte-range request, the
   sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field
   specifying the current length of the selected representation
   (<xref target="header.content-range"/>).
</t>
<figure>
<preamble>For example:</preamble>
<artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
</artwork></figure>
<aside>
  <t>
    &Note; Because servers are free to ignore <x:ref>Range</x:ref>, many
    implementations will simply respond with the entire selected representation
    in a <x:ref>200 (OK)</x:ref> response. That is partly because
    most clients are prepared to receive a <x:ref>200 (OK)</x:ref> to
    complete the task (albeit less efficiently) and partly because clients
    might not stop making an invalid partial request until they have received
    a complete representation. Thus, clients cannot depend on receiving a
    <x:ref>416 (Range Not Satisfiable)</x:ref> response even when it is most
    appropriate.
  </t>
</aside>
</section>

<section title="417 Expectation Failed" anchor="status.417">
  <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/>
  <x:anchor-alias value="417 (Expectation Failed)"/>
<t>
   The <x:dfn>417 (Expectation Failed)</x:dfn> status code indicates that the
   expectation given in the request's <x:ref>Expect</x:ref> header field
   (<xref target="header.expect"/>) could not be met by at least one of the
   inbound servers.
</t>
</section>

<section title="426 Upgrade Required" anchor="status.426">
  <iref primary="true" item="426 Upgrade Required (status code)" x:for-anchor=""/>
  <x:anchor-alias value="426 (Upgrade Required)"/>
<t>
   The <x:dfn>426 (Upgrade Required)</x:dfn> status code indicates that the
   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.
   The server &MUST; send an <x:ref>Upgrade</x:ref> header field in a 426
   response to indicate the required protocol(s) (<xref target="header.upgrade"/>).
</t>
<figure>
<preamble>Example:</preamble>
<artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: <x:length-of target="s426body"/>
Content-Type: text/plain

<x:span anchor="s426body">This service requires use of the HTTP/3.0 protocol.
</x:span></artwork></figure>
</section>
</section>

<section title="Server Error 5xx" anchor="status.5xx">
  <x:anchor-alias value="5xx"/>
  <x:anchor-alias value="5xx (Server Error)"/>
  <iref primary="true" item="5xx Server Error (status code class)" x:for-anchor=""/>
  <iref primary="true" item="Status Codes Classes" subitem="5xx Server Error" x:for-anchor=""/>
<t>
   The <x:dfn>5xx (Server Error)</x:dfn> class of status code indicates that
   the server is aware that it has erred or is incapable of performing the
   requested method.
   Except when responding to a HEAD request, the server &SHOULD; send a
   representation containing an explanation of the error situation, and
   whether it is a temporary or permanent condition.
   A user agent &SHOULD; display any included representation to the user.
   These response codes are applicable to any request method.
</t>

<section title="500 Internal Server Error" anchor="status.500">
  <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/>
  <x:anchor-alias value="500 (Internal Server Error)"/>
<t>
   The <x:dfn>500 (Internal Server Error)</x:dfn> status code indicates that
   the server encountered an unexpected condition that prevented it from
   fulfilling the request.
</t>
</section>

<section title="501 Not Implemented" anchor="status.501">
  <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/>
  <x:anchor-alias value="501 (Not Implemented)"/>
<t>
   The <x:dfn>501 (Not Implemented)</x:dfn> status code indicates that the
   server does not support the functionality required to fulfill the request.
   This is the appropriate response when the server does not recognize the
   request method and is not capable of supporting it for any resource.
</t>
<t>
   A 501 response is cacheable by default; i.e., unless otherwise indicated by
   the method definition or explicit cache controls (see <xref target="heuristic.freshness"/>).
</t>

</section>

<section title="502 Bad Gateway" anchor="status.502">
  <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/>
  <x:anchor-alias value="502 (Bad Gateway)"/>
<t>
   The <x:dfn>502 (Bad Gateway)</x:dfn> status code indicates that the server,
   while acting as a gateway or proxy, received an invalid response from an
   inbound server it accessed while attempting to fulfill the request.
</t>
</section>

<section title="503 Service Unavailable" anchor="status.503">
  <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/>
  <x:anchor-alias value="503 (Service Unavailable)"/>
<t>
   The <x:dfn>503 (Service Unavailable)</x:dfn> status code indicates that the
   server is currently unable to handle the request due to a temporary overload
   or scheduled maintenance, which will likely be alleviated after some delay.
   The server &MAY; send a <x:ref>Retry-After</x:ref> header field
   (<xref target="header.retry-after"/>) to suggest an appropriate
   amount of time for the client to wait before retrying the request.
</t>
<aside>
  <t>
    &Note; The existence of the 503 status code does not imply that a
    server has to use it when becoming overloaded. Some servers might
    simply refuse the connection.
  </t>
</aside>
</section>

<section title="504 Gateway Timeout" anchor="status.504">
  <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/>
  <x:anchor-alias value="504 (Gateway Timeout)"/>
<t>
   The <x:dfn>504 (Gateway Timeout)</x:dfn> status code indicates that the
   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
   complete the request.
</t>
</section>

<section title="505 HTTP Version Not Supported" anchor="status.505">
  <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/>
  <x:anchor-alias value="505 (HTTP Version Not Supported)"/>
<t>
   The <x:dfn>505 (HTTP Version Not Supported)</x:dfn> status code indicates
   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
   it is unable or unwilling to complete the request using the same major
   version as the client, as described in <xref target="protocol.version"/>, other than with this
   error message. The server &SHOULD; generate a representation for the 505
   response that describes why that version is not supported and what other
   protocols are supported by that server.
</t>
</section>
</section>

<section title="Status Code Extensibility" anchor="status.code.extensibility">
<t>
   Additional status codes, outside the scope of this specification, have been
   specified for use in HTTP. All such status codes ought to be registered
   within the "Hypertext Transfer Protocol (HTTP) Status Code Registry".
</t>

<section title="Status Code Registry" anchor="status.code.registry">
<t>
   The "Hypertext Transfer Protocol (HTTP) Status Code Registry", maintained
   by IANA at <eref target="https://www.iana.org/assignments/http-status-codes"/>,
   registers <x:ref>status-code</x:ref> numbers.
</t>
<t>
   A registration &MUST; include the following fields:
   <list style="symbols">
      <t>Status Code (3 digits)</t>
      <t>Short Description</t>
      <t>Pointer to specification text</t>
   </list>
</t>
<t>
   Values to be added to the HTTP status code namespace require IETF Review
   (see <xref target="RFC8126" x:fmt="," x:sec="4.8"/>).
</t>
</section>

<section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">
<t>
   When it is necessary to express semantics for a response that are not
   defined by current status codes, a new status code can be registered.
   Status codes are generic; they are potentially applicable to any resource,
   not just one particular media type, kind of resource, or application of
   HTTP. As such, it is preferred that new status codes be registered in a
   document that isn't specific to a single application.
</t>
<t>
   New status codes are required to fall under one of the categories
   defined in <xref target="status.codes"/>. To allow existing parsers to
   process the response message, new status codes cannot disallow a payload,
   although they can mandate a zero-length payload body.
</t>
<t>
   Proposals for new status codes that are not yet widely deployed ought to
   avoid allocating a specific number for the code until there is clear
   consensus that it will be registered; instead, early drafts can use a
   notation such as "4NN", or "3N0" .. "3N9", to indicate the class
   of the proposed status code(s) without consuming a number prematurely.
</t>
<t>
   The definition of a new status code ought to explain the request
   conditions that would cause a response containing that status code (e.g.,
   combinations of request header fields and/or method(s)) along with any 
   dependencies on response header fields (e.g., what fields are required,
   what fields can modify the semantics, and what header field semantics are
   further refined when used with the new status code).
</t>
<t>
   The definition of a new status code ought to specify whether or not it is
   cacheable. Note that all status codes can be cached if the response they
   occur in has explicit freshness information; however, status codes that are
   defined as being cacheable are allowed to be cached without explicit
   freshness information. Likewise, the definition of a status code can place
   constraints upon cache behavior. See <xref target="Caching"/> for more information.
</t>
<t>   
   Finally, the definition of a new status code ought to indicate whether the
   payload has any implied association with an identified resource (<xref
   target="identifying.payload"/>).
</t>
</section>
</section>
</section>

<section title="Response Header Fields" anchor="response.header.fields">
  <x:anchor-alias value="response-header"/>
<t>
   The response header fields allow the server to pass additional
   information about the response beyond what is placed in the status-line.
   These header fields give information about the server, about
   further access to the <x:ref>target resource</x:ref>, or about related
   resources.
</t>
<t>
   Although each response header field has a defined meaning, in general,
   the precise semantics might be further refined by the semantics of the
   request method and/or response status code. 
</t>

<section title="Control Data" anchor="response.control.data">
<t>
   Response header fields can supply control data that supplements the
   status code, directs caching, or instructs the client where to go next.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>

  <c>Age</c> <c><xref target="header.age"/></c>
  <c>Cache-Control</c> <c><xref target="header.cache-control"/></c>
  <c>Expires</c> <c><xref target="header.expires"/></c>
  <c>Date</c> <c><xref target="header.date"/></c>
  <c>Location</c> <c><xref target="header.location"/></c>
  <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
  <c>Vary</c> <c><xref target="header.vary"/></c>
  <c>Warning</c> <c><xref target="header.warning"/></c>
</texttable>

<section title="Origination Date" anchor="origination.date">

<section title="Date/Time Formats" anchor="http.date">
  <x:anchor-alias value="HTTP-date"/>
<t>
   Prior to 1995, there were three different formats commonly used by servers
   to communicate timestamps.  For compatibility with old implementations, all
   three are defined here. The preferred format is a fixed-length and
   single-zone subset of the date and time specification used by the
   Internet Message Format <xref target="RFC5322"/>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/>
  <x:ref>HTTP-date</x:ref>    = <x:ref>IMF-fixdate</x:ref> / <x:ref>obs-date</x:ref>
</artwork></figure>
<figure><preamble>An example of the preferred format is</preamble><artwork type="example" x:indent-with="  ">
Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
</artwork></figure>
<figure><preamble>Examples of the two obsolete formats are</preamble><artwork type="example" x:indent-with="  ">
Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
</artwork></figure>
<t>
   A recipient that parses a timestamp value in an HTTP header field &MUST;
   accept all three HTTP-date formats. When a sender generates a header field
   that contains one or more timestamps defined as HTTP-date,
   the sender &MUST; generate those timestamps in the IMF-fixdate format.
</t>
<t>
   An HTTP-date value represents time as an instance of Coordinated Universal
   Time (UTC). The first two formats indicate UTC by the 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.
   A sender that generates HTTP-date values from a local clock ought to use
   NTP (<xref target="RFC5905"/>) or some similar protocol to synchronize its
   clock to UTC.
</t>
<t anchor="preferred.date.format">
  <x:anchor-alias value="IMF-fixdate"/>
  <x:anchor-alias value="time-of-day"/>
  <x:anchor-alias value="hour"/>
  <x:anchor-alias value="minute"/>
  <x:anchor-alias value="second"/>
  <x:anchor-alias value="day-name"/>
  <x:anchor-alias value="day"/>
  <x:anchor-alias value="month"/>
  <x:anchor-alias value="year"/>
  <x:anchor-alias value="GMT"/>
  Preferred format:
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="IMF-fixdate"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>
  <x:ref>IMF-fixdate</x:ref>  = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
  ; fixed length/zone/capitalization subset of the format
  ; see <xref target="RFC5322" x:fmt="of" x:sec="3.3"/>
  
  <x:ref>day-name</x:ref>     = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive
               / <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive
               / <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive
               / <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive
               / <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive
               / <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive
               / <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive
               
  <x:ref>date1</x:ref>        = <x:ref>day</x:ref> <x:ref>SP</x:ref> <x:ref>month</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
               ; e.g., 02 Jun 1982

  <x:ref>day</x:ref>          = 2<x:ref>DIGIT</x:ref>
  <x:ref>month</x:ref>        = <x:abnf-char-sequence>"Jan"</x:abnf-char-sequence> ; "Jan", case-sensitive
               / <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive
               / <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive
               / <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive
               / <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive
               / <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive
               / <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive
               / <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive
               / <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive
               / <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive
               / <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive
               / <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive
  <x:ref>year</x:ref>         = 4<x:ref>DIGIT</x:ref>

  <x:ref>GMT</x:ref>          = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive

  <x:ref>time-of-day</x:ref>  = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref>
               ; 00:00:00 - 23:59:60 (leap second)
                 
  <x:ref>hour</x:ref>         = 2<x:ref>DIGIT</x:ref>               
  <x:ref>minute</x:ref>       = 2<x:ref>DIGIT</x:ref>               
  <x:ref>second</x:ref>       = 2<x:ref>DIGIT</x:ref>               
</artwork></figure>
<t anchor="obsolete.date.formats">
  <x:anchor-alias value="obs-date"/>
  <x:anchor-alias value="rfc850-date"/>
  <x:anchor-alias value="asctime-date"/>
  <x:anchor-alias value="date1"/>
  <x:anchor-alias value="date2"/>
  <x:anchor-alias value="date3"/>
  <x:anchor-alias value="day-name-l"/>
  Obsolete formats:
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="obs-date"/>
  <x:ref>obs-date</x:ref>     = <x:ref>rfc850-date</x:ref> / <x:ref>asctime-date</x:ref> 
</artwork></figure>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc850-date"/>
  <x:ref>rfc850-date</x:ref>  = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
  <x:ref>date2</x:ref>        = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref>
               ; e.g., 02-Jun-82

  <x:ref>day-name-l</x:ref>   = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence>    ; "Monday", case-sensitive
         / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence>       ; "Tuesday", case-sensitive
         / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive
         / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence>    ; "Thursday", case-sensitive
         / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence>          ; "Friday", case-sensitive
         / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence>    ; "Saturday", case-sensitive
         / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence>          ; "Sunday", case-sensitive
</artwork></figure>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/>
  <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
  <x:ref>date3</x:ref>        = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> ))
               ; e.g., Jun  2
</artwork></figure>
<t>
   HTTP-date is case sensitive.
   A sender &MUST-NOT; generate additional whitespace in an HTTP-date beyond
   that specifically included as SP in the grammar.
   The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,
   <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref>
   are the same as those defined for the Internet Message Format constructs
   with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
</t>
<t>
   Recipients of a timestamp value in rfc850-date format, which uses a
   two-digit year, &MUST; interpret a timestamp that appears to be more
   than 50 years in the future as representing the most recent year in the
   past that had the same last two digits.
</t>
<t>
   Recipients of timestamp values are encouraged to be robust in parsing
   timestamps unless otherwise restricted by the field definition.
   For example, messages are occasionally forwarded over HTTP from a non-HTTP
   source that might generate any of the date and time specifications defined
   by the Internet Message Format.
</t>
<aside>
  <t>
    &Note; HTTP requirements for the date/time stamp format apply only
    to their usage within the protocol stream. Implementations are
    not required to use these formats for user presentation, request
    logging, etc.
  </t>
</aside>
</section>

<section title="Date" anchor="header.date">
  <iref primary="true" item="Date header field" x:for-anchor=""/>
  <x:anchor-alias value="Date"/>
<t>
   The "Date" header field represents the date and time at which
   the message was originated, having the same semantics as the Origination
   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
   The field value is an HTTP-date, as defined in <xref target="http.date"/>.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
</artwork></figure>
<t>
   An example is
</t>
<figure><artwork type="example">
  Date: Tue, 15 Nov 1994 08:12:31 GMT
</artwork></figure>
<t>
   When a Date header field is generated, the sender &SHOULD; generate its
   field value as the best available approximation of the date and time of
   message generation. In theory, the date ought to represent the moment just
   before the payload is generated. In practice, the date can be generated at
   any time during message origination.
</t>
<t>
   An origin server &MUST-NOT; send a Date header field if it does not have a
   clock capable of providing a reasonable approximation of the current
   instance in Coordinated Universal Time.
   An origin server &MAY; send a Date header field if the response is in the
   <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref>
   class of status codes.
   An origin server &MUST; send a Date header field in all other cases.
</t>
<t>
   A recipient with a clock that receives a response message without a Date
   header field &MUST; record the time it was received and append a
   corresponding Date header field to the message's header section if it is
   cached or forwarded downstream.
</t>
<t>
   A user agent &MAY; send a Date header field in a request, though generally
   will not do so unless it is believed to convey useful information to the
   server. For example, custom applications of HTTP might convey a Date if
   the server is expected to adjust its interpretation of the user's request
   based on differences between the user agent and server clocks.
</t>
</section>
</section>

<section title="Location" anchor="header.location">
  <iref primary="true" item="Location header field" x:for-anchor=""/>
  <x:anchor-alias value="Location"/>
<t>
   The "Location" header field is used in some responses to refer to a
   specific resource in relation to the response. The type of relationship is
   defined by the combination of request method and status code semantics.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
  <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>
</artwork></figure>
<t>
   The field value consists of a single URI-reference. When it has the form
   of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>),
   the final value is computed by resolving it against the effective request
   URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>).
</t>
<t>
   For <x:ref>201 (Created)</x:ref> responses, the Location value refers to
   the primary resource created by the request.
   For <x:ref>3xx (Redirection)</x:ref> responses, the Location value refers
   to the preferred target resource for automatically redirecting the request.
</t>
<t>
   If the Location value provided in a <x:ref>3xx (Redirection)</x:ref>
   response does not have a fragment component, a user agent &MUST; process the
   redirection as if the value inherits the fragment component of the URI
   reference used to generate the request target (i.e., the redirection
   inherits the original reference's fragment, if any).
</t>
<figure>
<preamble>For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a
   <x:ref>303 (See Other)</x:ref> response containing the header field:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
<artwork type="example">
  Location: /People.html#tim
</artwork>
<postamble>which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim"</postamble>
</figure>
<figure>
<preamble>Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry" might result in a
   <x:ref>301 (Moved Permanently)</x:ref> response containing the header
   field:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
<artwork type="example">
  Location: http://www.example.net/index.html
</artwork>
<postamble>which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the original fragment
   identifier.</postamble>
</figure>
<t>
   There are circumstances in which a fragment identifier in a Location
   value would not be appropriate. For example, the Location header field in a
   <x:ref>201 (Created)</x:ref> response is supposed to provide a URI that is
   specific to the created resource.
</t>
<aside>
  <t>
    &Note; Some recipients attempt to recover from Location fields
    that are not valid URI references. This specification does not mandate or
    define such processing, but does allow it for the sake of robustness.
  </t>
</aside>
<aside>
  <t>
    &Note; The <x:ref>Content-Location</x:ref> header field
    (<xref target="header.content-location"/>) differs from Location in that the
    Content-Location refers to the most specific resource corresponding to the
    enclosed representation. It is therefore possible for a response to contain
    both the Location and Content-Location header fields.
  </t>
</aside>
</section>

<section title="Retry-After" anchor="header.retry-after">
  <iref primary="true" item="Retry-After header field" x:for-anchor=""/>
  <x:anchor-alias value="Retry-After"/>
<t>
   Servers send the "Retry-After" header field to indicate how long the user
   agent ought to wait before making a follow-up request. When sent with a
   <x:ref>503 (Service Unavailable)</x:ref> response, Retry-After indicates
   how long the service is expected to be unavailable to the client.
   When sent with any <x:ref>3xx (Redirection)</x:ref> response, Retry-After
   indicates the minimum time that the user agent is asked to wait before
   issuing the redirected request.
</t>
<t>
   The value of this field can be either an HTTP-date or a number
   of seconds to delay after the response is received.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/>
  <x:ref>Retry-After</x:ref> = <x:ref>HTTP-date</x:ref> / <x:ref>delay-seconds</x:ref>
</artwork></figure>
<t anchor="rule.delay-seconds">
  <x:anchor-alias value="delay-seconds"/>
   A delay-seconds value is a non-negative decimal integer, representing time
   in seconds.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delay-seconds"/>
  <x:ref>delay-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
</artwork></figure>
<t>
   Two examples of its use are
</t>
<figure><artwork type="example">
  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  Retry-After: 120
</artwork></figure>
<t>
   In the latter example, the delay is 2 minutes.
</t>
</section>

<section title="Vary" anchor="header.vary">
   <iref item="Vary header field" primary="true" x:for-anchor="" />
   <x:anchor-alias value="Vary"/>
<t>
   The "Vary" header field in a response describes what parts of a request
   message, aside from the method, Host header field, and request target,
   might influence the origin server's process for selecting and representing
   this response. The value consists of either a single asterisk ("*") or a
   list of header field names (case-insensitive).
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Vary"/>
  <x:ref>Vary</x:ref> = "*" / 1#<x:ref>field-name</x:ref>
</artwork></figure>
<t>
   A Vary field value of "*" signals that anything about the request might
   play a role in selecting the response representation, possibly including
   elements outside the message syntax (e.g., the client's network address).
   A recipient will not be able to determine whether this response is
   appropriate for a later request without forwarding the request to the
   origin server. A proxy &MUST-NOT; generate a Vary field with a "*" value.
</t>
<t>
   A Vary field value consisting of a comma-separated list of names indicates
   that the named request header fields, known as the selecting header fields,
   might have a role in selecting the representation. The potential selecting
   header fields are not limited to those defined by this specification.
</t>
<figure><preamble>For example, a response that contains</preamble><artwork type="example">
  Vary: accept-encoding, accept-language
</artwork><postamble>indicates that the origin server might have used the
   request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref>
   fields (or lack thereof) as determining factors while choosing the content
   for this response.
</postamble></figure>
<t>
   An origin server might send Vary with a list of fields for two purposes:
</t>
<ol>
  <li>
    <t>
       To inform cache recipients that they &MUST-NOT; use this response
       to satisfy a later request unless the later request has the
       same values for the listed fields as the original request
       (<xref target="caching.negotiated.responses"/>). In other words, Vary expands the cache key
       required to match a new request to the stored cache entry.
    </t>
  </li>
  <li>
    <t>
       To inform user agent recipients that this response is subject to
       content negotiation (<xref target="request.conneg"/>) and that a
       different representation might be sent in a subsequent request if
       additional parameters are provided in the listed header fields
       (<x:ref>proactive negotiation</x:ref>).
    </t>
  </li>
</ol>
<t>
   An origin server &SHOULD; send a Vary header field when its algorithm for
   selecting a representation varies based on aspects of the request message
   other than the method and request target, unless the variance cannot be
   crossed or the origin server has been deliberately configured to prevent
   cache transparency. For example, there is no need to send the Authorization
   field name in Vary because reuse across users is constrained by the field
   definition (<xref target="header.authorization"/>). Likewise, an origin server might use
   Cache-Control directives (<xref target="header.cache-control"/>) to supplant Vary if it
   considers the variance less significant than the performance cost of Vary's
   impact on caching.
</t>
</section>
</section>

<section title="Validators" anchor="response.validator">
   <iref primary="true" item="metadata"/>
   <iref primary="true" item="validator"/>
   <iref item="selected representation"/>
<t>
   Validator header fields convey metadata about the
   <x:ref>selected representation</x:ref> (<xref target="representations"/>).
   In responses to safe requests, validator fields describe the selected
   representation chosen by the origin server while handling the response.
   Note that, depending on the status code semantics, the
   <x:ref>selected representation</x:ref> for a given response is not
   necessarily the same as the representation enclosed as response payload.
</t>
<t>
   In a successful response to a state-changing request, validator fields
   describe the new representation that has replaced the prior
   <x:ref>selected representation</x:ref> as a result of processing the
   request.
</t>
<t>
   For example, an ETag header field in a <x:ref>201 (Created)</x:ref> response communicates the
   entity-tag of the newly created resource's representation, so that it can
   be used in later conditional requests to prevent the "lost update"
   problem <xref target="preconditions"/>.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol>
  <ttcol>Defined in...</ttcol>

  <c>ETag</c> <c><xref target="header.etag"/></c>
  <c>Last-Modified</c> <c><xref target="header.last-modified"/></c>
</texttable>

<t>
   This specification defines two forms of metadata that are commonly used
   to observe resource state and test for preconditions: modification dates
   (<xref target="header.last-modified"/>) and opaque entity tags
   (<xref target="header.etag"/>).  Additional metadata that reflects resource state
   has been defined by various extensions of HTTP, such as Web Distributed
   Authoring and Versioning (WebDAV, <xref target="RFC4918"/>), that are beyond the scope of this specification.
   A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>"
   when it is used within a precondition.
</t>

<section title="Weak versus Strong" anchor="weak.and.strong.validators">
   <iref primary="true" item="validator" subitem="weak"/>
   <iref primary="true" item="validator" subitem="strong"/>
<t>
   Validators come in two flavors: strong or weak.  Weak validators are easy
   to generate but are far less useful for comparisons.  Strong validators
   are ideal for comparisons but can be very difficult (and occasionally
   impossible) to generate efficiently.  Rather than impose that all forms
   of resource adhere to the same strength of validator, HTTP exposes the
   type of validator in use and imposes restrictions on when weak validators
   can be used as preconditions.
</t>
<t>
   A "strong validator" is representation metadata that changes value whenever
   a change occurs to the representation data that would be observable in the
   payload body of a <x:ref>200 (OK)</x:ref> response to GET.
</t>
<t>   
   A strong validator might change for reasons other than a change to the
   representation data, such as when a
   semantically significant part of the representation metadata is changed
   (e.g., <x:ref>Content-Type</x:ref>), but it is in the best interests of the
   origin server to only change the value when it is necessary to invalidate
   the stored responses held by remote caches and authoring tools.
</t>
<t>
   Cache entries might persist for arbitrarily long periods, regardless
   of expiration times.  Thus, a cache might attempt to validate an
   entry using a validator that it obtained in the distant past.
   A strong validator is unique across all versions of all
   representations associated with a particular resource over time.
   However, there is no implication of uniqueness across representations
   of different resources (i.e., the same strong validator might be
   in use for representations of multiple resources at the same time
   and does not imply that those representations are equivalent).
</t>
<t>
   There are a variety of strong validators used in practice.  The best are
   based on strict revision control, wherein each change to a representation
   always results in a unique node name and revision identifier being assigned
   before the representation is made accessible to GET.  A collision-resistant hash
   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
   does not need to be recalculated every time a validation request is
   received.  However, if a resource has distinct representations that differ
   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
   server needs to incorporate additional information in the validator to
   distinguish those representations.
</t>
<t>
   In contrast, a "weak validator" is representation metadata that
   might not change for every change to the representation data.  This
   weakness might be due to limitations in how the value is calculated, such
   as clock resolution, an inability to ensure uniqueness for all possible
   representations of the resource, or a desire of the resource owner
   to group representations by some self-determined set of equivalency
   rather than unique sequences of data.  An origin server &SHOULD; change a
   weak entity-tag whenever it considers prior representations to be
   unacceptable as a substitute for the current representation. In other words,
   a weak entity-tag ought to change whenever the origin server wants caches to
   invalidate old responses.
</t>
<t>
   For example, the representation of a weather report that changes in
   content every second, based on dynamic measurements, might be grouped
   into sets of equivalent representations (from the origin server's
   perspective) with the same weak validator in order to allow cached
   representations to be valid for a reasonable period of time (perhaps
   adjusted dynamically based on server load or weather quality).
   Likewise, a representation's modification time, if defined with only
   one-second resolution, might be a weak validator if it is possible
   for the representation to be modified twice during a single second and
   retrieved between those modifications.
</t>
<t>
   Likewise, a validator is weak if it is shared by two or more
   representations of a given resource at the same time, unless those
   representations have identical representation data. For example, if the
   origin server sends the same validator for a representation with a gzip
   content coding applied as it does for a representation with no content
   coding, then that validator is weak. However, two simultaneous
   representations might share the same strong validator if they differ only
   in the representation metadata, such as when two different media types are
   available for the same representation data.
</t>
<t>
   Strong validators are usable for all conditional requests, including cache
   validation, partial content ranges, and "lost update" avoidance.
   Weak validators are only usable when the client does not require exact
   equality with previously obtained representation data, such as when
   validating a cache entry or limiting a web traversal to recent changes.
</t>
</section>

<section title="Last-Modified" anchor="header.last-modified">
  <iref primary="true" item="Last-Modified header field" x:for-anchor=""/>
  <x:anchor-alias value="Last-Modified"/>
<t>
   The "Last-Modified" header field in a response provides a timestamp
   indicating the date and time at which the origin server believes the
   selected representation was last modified, as determined at the conclusion
   of handling the request.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/>
  <x:ref>Last-Modified</x:ref> = <x:ref>HTTP-date</x:ref>
</artwork></figure>
<t>
   An example of its use is
</t>
<figure><artwork type="example">
  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
</artwork></figure>

<section title="Generation" anchor="lastmod.generation">
<t>
   An origin server &SHOULD; send Last-Modified for any selected
   representation for which a last modification date can be reasonably
   and consistently determined, since its use in conditional requests
   and evaluating cache freshness (<xref target="Caching"/>) results in a substantial
   reduction of HTTP traffic on the Internet and can be a significant
   factor in improving service scalability and reliability.
</t>
<t>
   A representation is typically the sum of many parts behind the
   resource interface.  The last-modified time would usually be
   the most recent time that any of those parts were changed.
   How that value is determined for any given resource is an
   implementation detail beyond the scope of this specification.
   What matters to HTTP is how recipients of the Last-Modified
   header field can use its value to make conditional requests
   and test the validity of locally cached responses.
</t>
<t>
   An origin server &SHOULD; obtain the Last-Modified value of the
   representation as close as possible to the time that it generates the
   <x:ref>Date</x:ref> field value for its response. This allows a recipient to
   make an accurate assessment of the representation's modification time,
   especially if the representation changes near the time that the
   response is generated.
</t>
<t>
   An origin server with a clock &MUST-NOT; send a Last-Modified date
   that is later than the server's time of message origination (<x:ref>Date</x:ref>).
   If the last modification time is derived from implementation-specific
   metadata that evaluates to some time in the future, according to the
   origin server's clock, then the origin server &MUST; replace that
   value with the message origination date. This prevents a future
   modification date from having an adverse impact on cache validation.
</t>
<t>
   An origin server without a clock &MUST-NOT; assign Last-Modified
   values to a response unless these values were associated
   with the resource by some other system or user with a reliable clock.
</t>
</section>

<section title="Comparison" anchor="lastmod.comparison">
<t>
   A Last-Modified time, when used as a validator in a request, is
   implicitly weak unless it is possible to deduce that it is strong,
   using the following rules:
  <list style="symbols">
     <t>The validator is being compared by an origin server to the
        actual current validator for the representation and,</t>
     <t>That origin server reliably knows that the associated representation did
        not change twice during the second covered by the presented
        validator.</t>
  </list>
</t>
<t>
   or
  <list style="symbols">
     <t>The validator is about to be used by a client in an <x:ref>If-Modified-Since</x:ref>,
        <x:ref>If-Unmodified-Since</x:ref>, or <x:ref>If-Range</x:ref> header
        field, because the client has a cache entry for the associated
        representation, and</t>
     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
        time when the origin server sent the original response, and</t>
     <t>The presented Last-Modified time is at least 60 seconds before
        the Date value.</t>
  </list>
</t>
<t>
   or
  <list style="symbols">
     <t>The validator is being compared by an intermediate cache to the
        validator stored in its cache entry for the representation, and</t>
     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
        time when the origin server sent the original response, and</t>
     <t>The presented Last-Modified time is at least 60 seconds before
        the Date value.</t>
  </list>
</t>
<t>
   This method relies on the fact that if two different responses were
   sent by the origin server during the same second, but both had the
   same Last-Modified time, then at least one of those responses would
   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
   arbitrary 60-second limit guards against the possibility that the Date and
   Last-Modified values are generated from different clocks or at somewhat
   different times during the preparation of the response. An
   implementation &MAY; use a value larger than 60 seconds, if it is
   believed that 60 seconds is too short.
</t>
</section>
</section>

<section title="ETag" anchor="header.etag">
  <iref primary="true" item="ETag header field" x:for-anchor=""/>
  <x:anchor-alias value="ETag"/>
  <x:anchor-alias value="entity-tag"/>
  <x:anchor-alias value="opaque-tag"/>
  <x:anchor-alias value="weak"/>
  <x:anchor-alias value="etagc"/>
<t>
   The "ETag" header field in a response provides the current entity-tag for
   the selected representation, as determined at the conclusion of handling
   the request.
   An entity-tag is an opaque validator for differentiating between
   multiple representations of the same resource, regardless of whether
   those multiple representations are due to resource state changes over
   time, content negotiation resulting in multiple representations being
   valid at the same time, or both. An entity-tag consists of an opaque
   quoted string, possibly prefixed by a weakness indicator.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/><iref primary="true" item="Grammar" subitem="etagc"/>
  <x:ref>ETag</x:ref>       = <x:ref>entity-tag</x:ref>

  <x:ref>entity-tag</x:ref> = [ <x:ref>weak</x:ref> ] <x:ref>opaque-tag</x:ref>
  <x:ref>weak</x:ref>       = <x:abnf-char-sequence>"W/"</x:abnf-char-sequence> ; "W/", case-sensitive
  <x:ref>opaque-tag</x:ref> = <x:ref>DQUOTE</x:ref> *<x:ref>etagc</x:ref> <x:ref>DQUOTE</x:ref>
  <x:ref>etagc</x:ref>      = %x21 / %x23-7E / <x:ref>obs-text</x:ref>
             ; <x:ref>VCHAR</x:ref> except double quotes, plus obs-text
</artwork></figure>
<aside>
  <t>
    &Note; Previously, opaque-tag was defined to be a quoted-string
    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>); thus, some recipients
    might perform backslash unescaping. Servers therefore ought to avoid
    backslash characters in entity tags.
  </t>
</aside>
<t>
   An entity-tag can be more reliable for validation than a modification
   date in situations where it is inconvenient to store modification
   dates, where the one-second resolution of HTTP date values is not
   sufficient, or where modification dates are not consistently maintained.
</t>
<figure><preamble>
  Examples:
</preamble>
<artwork type="example">
  ETag: "xyzzy"
  ETag: W/"xyzzy"
  ETag: ""
</artwork></figure>
<t>
   An entity-tag can be either a weak or strong validator, with
   strong being the default.  If an origin server provides an entity-tag
   for a representation and the generation of that entity-tag does not satisfy
   all of the characteristics of a strong validator
   (<xref target="weak.and.strong.validators"/>), then the origin server
   &MUST; mark the entity-tag as weak by prefixing its opaque value
   with "W/" (case-sensitive).
</t>

<section title="Generation" anchor="entity.tag.generation">
<t>
   The principle behind entity-tags is that only the service author
   knows the implementation of a resource well enough to select the
   most accurate and efficient validation mechanism for that resource,
   and that any such mechanism can be mapped to a simple sequence of
   octets for easy comparison.  Since the value is opaque, there is no
   need for the client to be aware of how each entity-tag is constructed.
</t>
<t>
   For example, a resource that has implementation-specific versioning
   applied to all changes might use an internal revision number, perhaps
   combined with a variance identifier for content negotiation, to
   accurately differentiate between representations.
   Other implementations might use a collision-resistant hash of
   representation content, a combination of various file attributes, or
   a modification timestamp that has sub-second resolution.
</t>
<t>
   An origin server &SHOULD; send an ETag for any selected representation
   for which detection of changes can be reasonably and consistently
   determined, since the entity-tag's use in conditional requests and
   evaluating cache freshness (<xref target="Caching"/>) can result in a substantial
   reduction of HTTP network traffic and can be a significant factor in
   improving service scalability and reliability.
</t>
</section>

<section title="Comparison" anchor="entity.tag.comparison">
  <x:anchor-alias value="validator.comparison"/>
  <x:anchor-alias value="strong comparison"/>
  <x:anchor-alias value="weak comparison"/>
<t>
   There are two entity-tag comparison functions, depending on whether or not
   the comparison context allows the use of weak validators:
  <list style="symbols">
     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
        are not weak and their opaque-tags match character-by-character.</t>
     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
        match character-by-character, regardless of either or both
        being tagged as "weak".</t>
  </list>
</t>
<t>
   The example below shows the results for a set of entity-tag pairs and both
   the weak and strong comparison function results:
</t>
<texttable align="left">
  <ttcol>ETag 1</ttcol>
  <ttcol>ETag 2</ttcol>
  <ttcol>Strong Comparison</ttcol>
  <ttcol>Weak Comparison</ttcol>

  <c>W/"1"</c>
  <c>W/"1"</c>
  <c>no match</c>
  <c>match</c>
  
  <c>W/"1"</c>
  <c>W/"2"</c>
  <c>no match</c>
  <c>no match</c>

  <c>W/"1"</c>
  <c>"1"</c>
  <c>no match</c>
  <c>match</c>

  <c>"1"</c>
  <c>"1"</c>
  <c>match</c>
  <c>match</c>
</texttable>
</section>

<section title="Example: Entity-Tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
<t>
   Consider a resource that is subject to content negotiation
   (<xref target="content.negotiation"/>), and where the representations sent in response to
   a GET request vary based on the <x:ref>Accept-Encoding</x:ref> request
   header field (<xref target="header.accept-encoding"/>):
</t>
<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
GET /index HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip

</artwork></figure>
<t>
   In this case, the response might or might not use the gzip content coding.
   If it does not, the response might look like:
</t>
<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: <x:length-of target="exbody2"/>
Vary: Accept-Encoding
Content-Type: text/plain

<x:span anchor="exbody2">Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
</x:span></artwork></figure>
<t>
   An alternative representation that does use gzip content coding would be:
</t>
<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip

<spanx>...binary data...</spanx></artwork></figure>
<aside>
  <t>
    &Note; Content codings are a property of the representation data,
    so a strong entity-tag for a content-encoded representation has to be
    distinct from the entity tag of an unencoded representation to prevent
    potential conflicts during cache updates and range requests. In contrast,
    transfer codings (<xref target="transfer.codings"/>) apply only during message transfer
    and do not result in distinct entity-tags.
  </t>
</aside>
</section>
</section>

<section title="When to Use Entity-Tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
<t>
   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
  <list style="symbols">
     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
        generate one.</t>

     <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if
        performance considerations support the use of weak entity-tags,
        or if it is unfeasible to send a strong entity-tag.</t>

     <t>&SHOULD; send a <x:ref>Last-Modified</x:ref> value if it is feasible to
        send one.</t>
  </list>
</t>
<t>
   In other words, the preferred behavior for an origin server
   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
   value in successful responses to a retrieval request.
</t>
<t>
   A client:
  <list style="symbols">
     <t>&MUST; send that entity-tag in any cache validation request (using
        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
        entity-tag has been provided by the origin server.</t>

     <t>&SHOULD; send the <x:ref>Last-Modified</x:ref> value in non-subrange
        cache validation requests (using <x:ref>If-Modified-Since</x:ref>)
        if only a Last-Modified value has been provided by the origin server.</t>

     <t>&MAY; send the <x:ref>Last-Modified</x:ref> value in subrange
        cache validation requests (using <x:ref>If-Unmodified-Since</x:ref>)
        if only a Last-Modified value has been provided by an HTTP/1.0 origin
        server. The user agent &SHOULD; provide a way to disable this, in case
        of difficulty.</t>

     <t>&SHOULD; send both validators in cache validation requests if both an
        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
        respond appropriately.</t>
  </list>
</t>
</section>
</section>

<section title="Authentication Challenges" anchor="response.auth">
<t>
   Authentication challenges indicate what mechanisms are available for the
   client to provide authentication credentials in future requests.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>

  <c>WWW-Authenticate</c> <c><xref target="header.www-authenticate"/></c>
  <c>Proxy-Authenticate</c> <c><xref target="header.proxy-authenticate"/></c>
</texttable>

<section title="WWW-Authenticate" anchor="header.www-authenticate">
  <iref primary="true" item="WWW-Authenticate header field" x:for-anchor=""/>
  <x:anchor-alias value="WWW-Authenticate"/>
<t>
   The "WWW-Authenticate" header field indicates the authentication scheme(s)
   and parameters applicable to the target resource.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
  <x:ref>WWW-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
</artwork></figure>
<t>
   A server generating a <x:ref>401 (Unauthorized)</x:ref> response
   &MUST; send a WWW-Authenticate header field containing at least one
   challenge.  A server &MAY; generate a WWW-Authenticate header field
   in other response messages to indicate that supplying credentials
   (or different credentials) might affect the response.
</t>
<t>
   A proxy forwarding a response &MUST-NOT; modify any
   <x:ref>WWW-Authenticate</x:ref> fields in that response.
</t>
<t>
   User agents are advised to take special care in parsing the field value, as
   it might contain more than one challenge, and each challenge can contain a
   comma-separated list of authentication parameters. Furthermore, the header
   field itself can occur multiple times.
</t>
<figure>
  <preamble>For instance:</preamble>
  <artwork type="example">
  WWW-Authenticate: Newauth realm="apps", type=1,
                    title="Login to \"apps\"", Basic realm="simple"
</artwork>
  <postamble>
  This header field contains two challenges; one for the "Newauth" scheme
  with a realm value of "apps", and two additional parameters "type" and
  "title", and another one for the "Basic" scheme with a realm value of
  "simple".
</postamble></figure>
<aside>
  <t>
    &Note; The challenge grammar production uses the list syntax as
    well. Therefore, a sequence of comma, whitespace, and comma can be
    considered either as applying to the preceding challenge, or to be an
    empty entry in the list of challenges. In practice, this ambiguity
    does not affect the semantics of the header field value and thus is
    harmless.
  </t>
</aside>
</section>

<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
  <iref primary="true" item="Proxy-Authenticate header field" x:for-anchor=""/>
  <x:anchor-alias value="Proxy-Authenticate"/>
<t>
   The "Proxy-Authenticate" header field consists of at least one
   challenge that indicates the authentication scheme(s) and parameters
   applicable to the proxy for this effective request URI
   (<xref target="effective.request.uri"/>).
   A proxy &MUST; send at least one Proxy-Authenticate header field in
   each <x:ref>407 (Proxy Authentication Required)</x:ref> response that it
   generates.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
  <x:ref>Proxy-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
</artwork></figure>
<t>
   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
   applies only to the next outbound client on the response chain.
   This is because only the client that chose a given proxy is likely to have
   the credentials necessary for authentication.  However, when multiple
   proxies are used within the same administrative domain, such as office and
   regional caching proxies within a large corporate network, it is common
   for credentials to be generated by the user agent and passed through the
   hierarchy until consumed.  Hence, in such a configuration, it will appear
   as if Proxy-Authenticate is being forwarded because each proxy will send
   the same challenge set.
</t>
<t>
   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
   apply to this header field as well; see <xref target="header.www-authenticate"/>
   for details.
</t>
</section>
</section>

<section title="Response Context" anchor="response.context">
<t>
   The remaining response header fields provide more information about
   the <x:ref>target resource</x:ref> for potential use in later requests.
</t>
<texttable align="left">
  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>

  <c>Accept-Ranges</c> <c><xref target="header.accept-ranges"/></c>
  <c>Allow</c> <c><xref target="header.allow"/></c>
  <c>Server</c> <c><xref target="header.server"/></c>
</texttable>

<section title="Accept-Ranges" anchor="header.accept-ranges">
  <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/>
  <x:anchor-alias value="Accept-Ranges"/>
  <x:anchor-alias value="acceptable-ranges"/>
<t>
   The "Accept-Ranges" header field allows a server to indicate that it
   supports range requests for the target resource.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
  <x:ref>Accept-Ranges</x:ref>     = <x:ref>acceptable-ranges</x:ref>
  <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none"
</artwork></figure>
<t>
   An origin server that supports byte-range requests for a given target
   resource &MAY; send
</t>
<figure><artwork type="example">
  Accept-Ranges: bytes
</artwork></figure>
<t>
   to indicate what range units are supported. A client &MAY; generate range
   requests without having received this header field for the resource
   involved. Range units are defined in <xref target="range.units"/>.
</t>
<t>
   A server that does not support any kind of range request for the target
   resource &MAY; send
</t>
<figure><artwork type="example">
  Accept-Ranges: none
</artwork></figure>
<t>
   to advise the client not to attempt a range request.
</t>
</section>

<section title="Allow" anchor="header.allow">
  <iref primary="true" item="Allow header field" x:for-anchor=""/>
  <x:anchor-alias value="Allow"/>
<t>
   The "Allow" header field lists the set of methods advertised as
   supported by the <x:ref>target resource</x:ref>. The purpose of this field
   is strictly to inform the recipient of valid request methods associated
   with the resource.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
  <x:ref>Allow</x:ref> = #<x:ref>method</x:ref>
</artwork></figure>
<t>
   Example of use:
</t>
<figure><artwork type="example">
  Allow: GET, HEAD, PUT
</artwork></figure>
<t>
   The actual set of allowed methods is defined by the origin server at the
   time of each request. An origin server &MUST; generate an Allow field in a
   <x:ref>405 (Method Not Allowed)</x:ref> response and &MAY; do so in any
   other response. An empty Allow field value indicates that the resource
   allows no methods, which might occur in a 405 response if the resource has
   been temporarily disabled by configuration.
</t>
<t>
   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need
   to understand all of the indicated methods in order to handle them
   according to the generic message handling rules.
</t>
</section>

<section title="Server" anchor="header.server">
  <iref primary="true" item="Server header field" x:for-anchor=""/>
  <x:anchor-alias value="Server"/>
<t>
   The "Server" header field contains information about the
   software used by the origin server to handle the request, which is often
   used by clients to help identify the scope of reported interoperability
   problems, to work around or tailor requests to avoid particular server
   limitations, and for analytics regarding server or operating system use.
   An origin server &MAY; generate a Server field in its responses.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/>
  <x:ref>Server</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
</artwork></figure>
<t>
   The Server field-value consists of one or more product identifiers, each
   followed by zero or more comments (<xref target="header.fields"/>), which together
   identify the origin server software and its significant subproducts.
   By convention, the product identifiers are listed in decreasing order of
   their significance for identifying the origin server software. Each product
   identifier consists of a name and optional version, as defined in
   <xref target="header.user-agent"/>.
</t>
<t>
   Example:
</t>
<figure><artwork type="example">
  Server: CERN/3.0 libwww/2.17
</artwork></figure>
<t>
   An origin server &SHOULD-NOT; generate a Server field containing needlessly
   fine-grained detail and &SHOULD; limit the addition of subproducts by third
   parties. Overly long and detailed Server field values increase response
   latency and potentially reveal internal implementation details that might
   make it (slightly) easier for attackers to find and exploit known security
   holes.
</t>
</section>
</section>
</section>

<section title="ABNF List Extension: #rule" anchor="abnf.extension">
<t>
   A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
   improve readability in the definitions of some header field values.
</t>
<t>
   A construct "#" is defined, similar to "*", for defining comma-delimited
   lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
   at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
   comma (",") and optional whitespace (OWS).   
</t>
<figure><preamble>
   In any production that uses the list construct, a sender &MUST-NOT;
   generate empty list elements. In other words, a sender &MUST; generate
   lists that satisfy the following syntax:
</preamble><artwork type="example">
  1#element =&gt; element *( OWS "," OWS element )
</artwork></figure>
<figure><preamble>
   and:
</preamble><artwork type="example">
  #element =&gt; [ 1#element ]
</artwork></figure>
<figure><preamble>
   and for n &gt;= 1 and m &gt; 1:
</preamble><artwork type="example">
  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
</artwork></figure>
<t>
   For compatibility with legacy list rules, a recipient &MUST; parse and ignore
   a reasonable number of empty list elements: enough to handle common mistakes
   by senders that merge values, but not so much that they could be used as a
   denial-of-service mechanism. In other words, a recipient &MUST; accept lists
   that satisfy the following syntax:
</t>
<figure><artwork type="example">
  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
  
  1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
</artwork></figure>
<t>
   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions: 
</t>
<figure><artwork type="example">
  example-list      = 1#example-list-elmt
  example-list-elmt = token ; see <xref target="field.components"/> 
</artwork></figure>
<t>
   Then the following are valid values for example-list (not including the
   double quotes, which are present for delimitation only):
</t>
<figure><artwork type="example">
  "foo,bar"
  "foo ,bar,"
  "foo , ,bar,charlie   "
</artwork></figure>
<t>
   In contrast, the following values would be invalid, since at least one
   non-empty element is required by the example-list production:
</t>
<figure><artwork type="example">
  ""
  ","
  ",   ,"
</artwork></figure>
<t>
   <xref target="collected.abnf"/> shows the collected ABNF for recipients
   after the list constructs have been expanded.
</t>
</section>

<section title="Security Considerations" anchor="security.considerations">
<t>
   This section is meant to inform developers, information providers, and
   users of known security concerns relevant to HTTP semantics and its
   use for transferring information over the Internet. Considerations related
   to message syntax, parsing, and routing are discussed in
   <xref target="Messaging-security.considerations"/>.
</t>
<t>
   The list of considerations below is not exhaustive. Most security concerns
   related to HTTP semantics are about securing server-side applications (code
   behind the HTTP interface), securing user agent processing of payloads
   received via HTTP, or secure use of the Internet in general, rather than
   security of the protocol. Various organizations maintain topical
   information and links to current research on Web application security
   (e.g., <xref target="OWASP"/>).
</t>

<section title="Establishing Authority" anchor="establishing.authority">
  <iref item="authoritative response" primary="true"/>
  <iref item="phishing" primary="true"/>
<t>
   HTTP relies on the notion of an <x:dfn>authoritative response</x:dfn>: a
   response that has been determined by (or at the direction of) the authority
   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
   response message origination. Providing a response from a non-authoritative
   source, such as a shared cache, is often useful to improve performance and
   availability, but only to the extent that the source can be trusted or
   the distrusted response can be safely used.
</t>
<t>
   Unfortunately, establishing authority can be difficult.
   For example, <x:dfn>phishing</x:dfn> is an attack on the user's perception
   of authority, where that perception can be misled by presenting similar
   branding in hypertext, possibly aided by userinfo obfuscating the authority
   component (see <xref target="http.uri"/>).
   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
   distinguishing (or rejecting) userinfo when present, and by not sending
   stored credentials and cookies when the referring document is from an
   unknown or untrusted source.
</t>
<t>
   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
   resolution service to determine where it can find authoritative responses.
   This means that any attack on a user's network host table, cached names, or
   name resolution libraries becomes an avenue for attack on establishing
   authority. Likewise, the user's choice of server for Domain Name Service
   (DNS), and the hierarchy of servers from which it obtains resolution
   results, could impact the authenticity of address mappings;
   DNS Security Extensions (DNSSEC, <xref target="RFC4033"/>) are one way to
   improve authenticity.
</t>
<t>
   Furthermore, after an IP address is obtained, establishing authority for
   an "http" URI is vulnerable to attacks on Internet Protocol routing.
</t>
<t>
   The "https" scheme (<xref target="https.uri"/>) is intended to prevent
   (or at least reveal) many of these potential attacks on establishing
   authority, provided that the negotiated TLS connection is secured and
   the client properly verifies that the communicating server's identity
   matches the target URI's authority component
   (see <xref target="RFC2818"/>). Correctly implementing such verification
   can be difficult (see <xref target="Georgiev"/>).
</t>
</section>

<section title="Risks of Intermediaries" anchor="risks.intermediaries">
<t>
   By their very nature, HTTP intermediaries are men-in-the-middle and, thus,
   represent an opportunity for man-in-the-middle attacks. Compromise of
   the systems on which the intermediaries run can result in serious security
   and privacy problems. Intermediaries might have access to security-related
   information, personal information about individual users and
   organizations, and proprietary information belonging to users and
   content providers. A compromised intermediary, or an intermediary
   implemented or configured without regard to security and privacy
   considerations, might be used in the commission of a wide range of
   potential attacks.
</t>
<t>
   Intermediaries that contain a shared cache are especially vulnerable
   to cache poisoning attacks, as described in <xref target="Caching-security.considerations"/>.
</t>
<t>
   Implementers need to consider the privacy and security
   implications of their design and coding decisions, and of the
   configuration options they provide to operators (especially the
   default configuration).
</t>
<t>
   Users need to be aware that intermediaries are no more trustworthy than
   the people who run them; HTTP itself cannot solve this problem.
</t>
</section>

<section title="Attacks Based on File and Path Names" anchor="attack.pathname">
<t>
   Origin servers frequently make use of their local file system to manage the
   mapping from effective request URI to resource representations.
   Most file systems are not designed to protect against malicious file
   or path names. Therefore, an origin server needs to avoid accessing
   names that have a special significance to the system when mapping the
   request target to files, folders, or directories.
</t>
<t>
   For example, UNIX, Microsoft Windows, and other operating systems use ".."
   as a path component to indicate a directory level above the current one,
   and they use specially named paths or file names to send data to system devices.
   Similar naming conventions might exist within other types of storage
   systems. Likewise, local storage systems have an annoying tendency to
   prefer user-friendliness over security when handling invalid or unexpected
   characters, recomposition of decomposed characters, and case-normalization
   of case-insensitive names.
</t>
<t>
   Attacks based on such special names tend to focus on either denial-of-service
   (e.g., telling the server to read from a COM port) or disclosure
   of configuration and source files that are not meant to be served.
</t>
</section>

<section title="Attacks Based on Command, Code, or Query Injection" anchor="attack.injection">
<t>
   Origin servers often use parameters within the URI as a
   means of identifying system services, selecting database entries, or
   choosing a data source. However, data received in a request cannot be
   trusted. An attacker could construct any of the request data elements
   (method, request-target, header fields, or body) to contain data that might
   be misinterpreted as a command, code, or query when passed through a
   command invocation, language interpreter, or database interface.
</t>
<t>
   For example, SQL injection is a common attack wherein additional query
   language is inserted within some part of the request-target or header
   fields (e.g., <x:ref>Host</x:ref>, <x:ref>Referer</x:ref>, etc.).
   If the received data is used directly within a SELECT statement, the
   query language might be interpreted as a database command instead of a
   simple string value. This type of implementation vulnerability is extremely
   common, in spite of being easy to prevent.
</t>
<t>
   In general, resource implementations ought to avoid use of request data
   in contexts that are processed or interpreted as instructions.  Parameters
   ought to be compared to fixed strings and acted upon as a result of that
   comparison, rather than passed through an interface that is not prepared
   for untrusted data. Received data that isn't based on fixed parameters
   ought to be carefully filtered or encoded to avoid being misinterpreted.
</t>
<t>
   Similar considerations apply to request data when it is stored and later
   processed, such as within log files, monitoring tools, or when included
   within a data format that allows embedded scripts.
</t>
</section>

<section title="Attacks via Protocol Element Length" anchor="attack.protocol.element.length">
<t>
   Because HTTP uses mostly textual, character-delimited fields, parsers are
   often vulnerable to attacks based on sending very long (or very slow)
   streams of data, particularly where an implementation is expecting a
   protocol element with no predefined length
   (<xref target="parsing-elements"/>).
</t>
<t>
   To promote interoperability, specific recommendations are made for minimum
   size limits on request-line (<xref target="request.line"/>)
   and header fields (<xref target="header.fields"/>). These are
   minimum recommendations, chosen to be supportable even by implementations
   with limited resources; it is expected that most implementations will
   choose substantially higher limits.
</t>
<t>
   A server can reject a message that
   has a request-target that is too long (<xref target="status.414"/>) or a request payload
   that is too large (<xref target="status.413"/>). Additional status codes related to
   capacity limits have been defined by extensions to HTTP
   <xref target="RFC6585"/>.
</t>
<t>
   Recipients ought to carefully limit the extent to which they process other
   protocol elements, including (but not limited to) request methods, response
   status phrases, header field-names, numeric values, and body chunks.
   Failure to limit such processing can result in buffer overflows, arithmetic
   overflows, or increased vulnerability to denial-of-service attacks.
</t>
</section>

<section title="Disclosure of Personal Information" anchor="personal.information">
<t>
   Clients are often privy to large amounts of personal information,
   including both information provided by the user to interact with resources
   (e.g., the user's name, location, mail address, passwords, encryption
   keys, etc.) and information about the user's browsing activity over
   time (e.g., history, bookmarks, etc.). Implementations need to
   prevent unintentional disclosure of personal information.
</t>
</section>

<section title="Privacy of Server Log Information" anchor="privacy.of.server.log.information">
<t>
   A server is in the position to save personal data about a user's requests
   over time, which might identify their reading patterns or subjects of
   interest.  In particular, log information gathered at an intermediary
   often contains a history of user agent interaction, across a multitude
   of sites, that can be traced to individual users.
</t>
<t>
   HTTP log information is confidential in nature; its handling is often
   constrained by laws and regulations.  Log information needs to be securely
   stored and appropriate guidelines followed for its analysis.
   Anonymization of personal information within individual entries helps,
   but it is generally not sufficient to prevent real log traces from being
   re-identified based on correlation with other access characteristics.
   As such, access traces that are keyed to a specific client are unsafe to
   publish even if the key is pseudonymous.
</t>
<t>
   To minimize the risk of theft or accidental publication, log information
   ought to be purged of personally identifiable information, including
   user identifiers, IP addresses, and user-provided query parameters,
   as soon as that information is no longer necessary to support operational
   needs for security, auditing, or fraud control.
</t>
</section>

<section title="Disclosure of Sensitive Information in URIs" anchor="sensitive.information.in.uris">
<t>
   URIs are intended to be shared, not secured, even when they identify secure
   resources. URIs are often shown on displays, added to templates when a page
   is printed, and stored in a variety of unprotected bookmark lists.
   It is therefore unwise to include information within a URI that
   is sensitive, personally identifiable, or a risk to disclose.
</t>
<t>
   Authors of services ought to avoid GET-based forms for the submission of
   sensitive data because that data will be placed in the request-target. Many
   existing servers, proxies, and user agents log or display the request-target
   in places where it might be visible to third parties. Such services ought
   to use POST-based form submission instead.
</t>
<t>
   Since the <x:ref>Referer</x:ref> header field tells a target site about the
   context that resulted in a request, it has the potential to reveal
   information about the user's immediate browsing history and any personal
   information that might be found in the referring resource's URI.
   Limitations on the Referer header field are described in <xref target="header.referer"/> to
   address some of its security considerations.
</t>
</section>

<section title="Disclosure of Fragment after Redirects" anchor="fragment.disclosure">
<t>
   Although fragment identifiers used within URI references are not sent
   in requests, implementers ought to be aware that they will be visible to
   the user agent and any extensions or scripts running as a result of the
   response. In particular, when a redirect occurs and the original request's
   fragment identifier is inherited by the new reference in
   <x:ref>Location</x:ref> (<xref target="header.location"/>), this might
   have the effect of disclosing one site's fragment to another site.
   If the first site uses personal information in fragments, it ought to
   ensure that redirects to other sites include a (possibly empty) fragment
   component in order to block that inheritance.
</t>
</section>

<section title="Disclosure of Product Information" anchor="disclosure.product.information">
<t>
   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>),
   <x:ref>Via</x:ref> (<xref target="header.via"/>), and
   <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields often
   reveal information about the respective sender's software systems.
   In theory, this can make it easier for an attacker to exploit known
   security holes; in practice, attackers tend to try all potential holes
   regardless of the apparent software versions being used.
</t>
<t>
   Proxies that serve as a portal through a network firewall ought to take
   special precautions regarding the transfer of header information that might
   identify hosts behind the firewall. The <x:ref>Via</x:ref> header field
   allows intermediaries to replace sensitive machine names with pseudonyms.
</t>
</section>

<section title="Browser Fingerprinting" anchor="fingerprinting">
<t>
   Browser fingerprinting is a set of techniques for identifying a specific
   user agent over time through its unique set of characteristics. These
   characteristics might include information related to its TCP behavior,
   feature capabilities, and scripting environment, though of particular
   interest here is the set of unique characteristics that might be
   communicated via HTTP. Fingerprinting is considered a privacy concern
   because it enables tracking of a user agent's behavior over time without
   the corresponding controls that the user might have over other forms of
   data collection (e.g., cookies). Many general-purpose user agents
   (i.e., Web browsers) have taken steps to reduce their fingerprints.
</t>
<t>
   There are a number of request header fields that might reveal information
   to servers that is sufficiently unique to enable fingerprinting.
   The <x:ref>From</x:ref> header field is the most obvious, though it is
   expected that From will only be sent when self-identification is desired by
   the user. Likewise, Cookie header fields are deliberately designed to
   enable re-identification, so fingerprinting concerns only apply to
   situations where cookies are disabled or restricted by the user agent's
   configuration.
</t>
<t>
   The <x:ref>User-Agent</x:ref> header field might contain enough information
   to uniquely identify a specific device, usually when combined with other
   characteristics, particularly if the user agent sends excessive details
   about the user's system or extensions. However, the source of unique
   information that is least expected by users is
   <x:ref>proactive negotiation</x:ref> (<xref target="request.conneg"/>),
   including the <x:ref>Accept</x:ref>, <x:ref>Accept-Charset</x:ref>,
   <x:ref>Accept-Encoding</x:ref>, and <x:ref>Accept-Language</x:ref>
   header fields.
</t>
<t>
   In addition to the fingerprinting concern, detailed use of the
   <x:ref>Accept-Language</x:ref> header field can reveal information the
   user might consider to be of a private nature. For example, understanding
   a given language set might be strongly correlated to membership in a
   particular ethnic group.
   An approach that limits such loss of privacy would be for a user agent
   to omit the sending of Accept-Language except for sites that have been
   whitelisted, perhaps via interaction after detecting a <x:ref>Vary</x:ref>
   header field that indicates language negotiation might be useful.
</t>
<t>
   In environments where proxies are used to enhance privacy, user agents
   ought to be conservative in sending proactive negotiation header fields.
   General-purpose user agents that provide a high degree of header field
   configurability ought to inform users about the loss of privacy that might
   result if too much detail is provided. As an extreme privacy measure,
   proxies could filter the proactive negotiation header fields in relayed
   requests.
</t>
</section>

<section title="Validator Retention" anchor="security.validators">
<t>
   The validators defined by this specification are not intended to ensure
   the validity of a representation, guard against malicious changes, or
   detect man-in-the-middle attacks. At best, they enable more efficient cache
   updates and optimistic concurrent writes when all participants are behaving
   nicely. At worst, the conditions will fail and the client will receive a
   response that is no more harmful than an HTTP exchange without conditional
   requests.
</t>
<t>
   An entity-tag can be abused in ways that create privacy risks. For example,
   a site might deliberately construct a semantically invalid entity-tag that
   is unique to the user or user agent, send it in a cacheable response with a
   long freshness time, and then read that entity-tag in later conditional
   requests as a means of re-identifying that user or user agent. Such an
   identifying tag would become a persistent identifier for as long as the
   user agent retained the original cache entry. User agents that cache
   representations ought to ensure that the cache is cleared or replaced
   whenever the user performs privacy-maintaining actions, such as clearing
   stored cookies or changing to a private browsing mode.
</t>
</section>

<section title="Denial-of-Service Attacks Using Range" anchor="overlapping.ranges">
<t>
   Unconstrained multiple range requests are susceptible to denial-of-service
   attacks because the effort required to request many overlapping ranges of
   the same data is tiny compared to the time, memory, and bandwidth consumed
   by attempting to serve the requested data in many parts.
   Servers ought to ignore, coalesce, or reject egregious range requests, such
   as requests for more than two overlapping ranges or for many small ranges
   in a single set, particularly when the ranges are requested out of order
   for no apparent reason. Multipart range requests are not designed to
   support random access.
</t>
</section>

<section title="Authentication Considerations" anchor="security.auth">
<t>
   Everything about the topic of HTTP authentication is a security
   consideration, so the list of considerations below is not exhaustive.
   Furthermore, it is limited to security considerations regarding the
   authentication framework, in general, rather than discussing all of the
   potential considerations for specific authentication schemes (which ought
   to be documented in the specifications that define those schemes).
   Various organizations maintain topical information and links to current
   research on Web application security (e.g., <xref target="OWASP"/>),
   including common pitfalls for implementing and using the authentication
   schemes found in practice.
</t>

<section title="Confidentiality of Credentials" anchor="confidentiality.of.credentials">
<t>
   The HTTP authentication framework does not define a single mechanism for
   maintaining the confidentiality of credentials; instead, each
   authentication scheme defines how the credentials are encoded prior to
   transmission. While this provides flexibility for the development of future
   authentication schemes, it is inadequate for the protection of existing
   schemes that provide no confidentiality on their own, or that do not
   sufficiently protect against replay attacks. Furthermore, if the server
   expects credentials that are specific to each individual user, the exchange
   of those credentials will have the effect of identifying that user even if
   the content within credentials remains confidential.
</t>
<t>
   HTTP depends on the security properties of the underlying transport- or
   session-level connection to provide confidential transmission of header
   fields. In other words, if a server limits access to authenticated users
   using this framework, the server needs to ensure that the connection is
   properly secured in accordance with the nature of the authentication
   scheme used. For example, services that depend on individual user
   authentication often require a connection to be secured with TLS
   ("Transport Layer Security", <xref target="RFC5246"/>) prior to exchanging
   any credentials.
</t>
</section>

<section title="Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
<t>
   Existing HTTP clients and user agents typically retain authentication
   information indefinitely. HTTP does not provide a mechanism for the
   origin server to direct clients to discard these cached credentials, since
   the protocol has no awareness of how credentials are obtained or managed
   by the user agent. The mechanisms for expiring or revoking credentials can
   be specified as part of an authentication scheme definition.
</t>
<t>
   Circumstances under which credential caching can interfere with the
   application's security model include but are not limited to:
  <list style="symbols">
     <t>Clients that have been idle for an extended period, following
        which the server might wish to cause the client to re-prompt the
        user for credentials.</t>

     <t>Applications that include a session termination indication
        (such as a "logout" or "commit" button on a page) after which
        the server side of the application "knows" that there is no
        further reason for the client to retain the credentials.</t>
  </list>
</t>
<t>
   User agents that cache credentials are encouraged to provide a readily
   accessible mechanism for discarding cached credentials under user control.
</t>
</section>

<section title="Protection Spaces" anchor="protection.spaces">
<t>
  Authentication schemes that solely rely on the "realm" mechanism for
  establishing a protection space will expose credentials to all resources on
  an origin server. Clients that have successfully made authenticated requests
  with a resource can use the same authentication credentials for other
  resources on the same origin server. This makes it possible for a different
  resource to harvest authentication credentials for other resources.
</t>
<t>
  This is of particular concern when an origin server hosts resources for multiple
  parties under the same canonical root URI (<xref target="protection.space"/>).
  Possible mitigation strategies include restricting direct access to
  authentication credentials (i.e., not making the content of the
  <x:ref>Authorization</x:ref> request header field available), and separating protection
  spaces by using a different host name (or port number) for each party.
</t>
</section>
</section>
</section>

<section title="IANA Considerations" anchor="IANA.considerations" removeInRFC="true">
<t>
   The change controller for the following registrations is:
   "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</t>

<section title="URI Scheme Registration" anchor="uri.scheme.registration">
<t>
   Please update the registry of URI Schemes <xref target="BCP115"/> at
   <eref target="https://www.iana.org/assignments/uri-schemes/"/> with the
   permanent schemes listed in the first table of <xref target="resources"/>.
</t>
</section>

<section title="Method Registration" anchor="method.registration">
<t>
  Please update the "Hypertext Transfer Protocol (HTTP) Method Registry" at
  <eref target="https://www.iana.org/assignments/http-methods"/> with the
  registration procedure of <xref target="method.registry"/> and the method
  names summarized in the table of <xref target="method.properties"/>.
</t>
</section>

<section title="Status Code Registration" anchor="status.code.registration">
<t>
   Please update the "Hypertext Transfer Protocol (HTTP) Status Code Registry"
   at <eref target="https://www.iana.org/assignments/http-status-codes"/> with
   the registration procedure of <xref target="status.code.registry"/> and the
   status code values summarized in the table of
   <xref target="overview.of.status.codes"/>.
</t>
</section>

<section title="Header Field Registration" anchor="header.field.registration">
<t>
   Please update the "Message Headers" registry of
   "Permanent Message Header Field Names" at
   <eref target="https://www.iana.org/assignments/message-headers"/> with the
   header field names listed in the table of <xref target="field.names"/>.
</t>
</section>

<section title="Authentication Scheme Registration" anchor="auth.scheme.registration">
<t>
   Please update the
   "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
   at <eref target="https://www.iana.org/assignments/http-authschemes"/> with
   the registration procedure of <xref target="auth.scheme.registry"/>.
   No authentication schemes are defined in this document.
</t>
</section>

<section title="Content Coding Registration" anchor="content.coding.registration">
<t>
   Please update the "HTTP Content Coding Registry" at
   <eref target="https://www.iana.org/assignments/http-parameters/"/>
   with the registration procedure of <xref target="content.coding.registry"/>
   and the content coding names summarized in the table of
   <xref target="content.codings"/>.
</t>
</section>

<section title="Range Unit Registration" anchor="range.unit.registration">
<t>
   Please update the "HTTP Range Unit Registry" at
   <eref target="https://www.iana.org/assignments/http-parameters/"/>
   with the registration procedure of <xref target="range.unit.registry"/>
   and the range unit names summarized in the table of
   <xref target="range.units"/>.
</t>
</section>

<section title="Media Type Registration" anchor="media.type.reg">
<t>
   Please update the "Media Types" registry at
   <eref target="https://www.iana.org/assignments/media-types"/>
   with the registration information in
   <xref target="multipart.byteranges"/>
   for the media type "multipart/byteranges".
</t>
</section>
</section>
</middle>
<back>

<references title="Normative References">

<reference anchor="Messaging">
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging-&ID-VERSION;"/>
  <x:source href="draft-ietf-httpbis-messaging-latest.xml" basename="draft-ietf-httpbis-messaging-latest">
    <x:has anchor="chunked.encoding"/>
    <x:has anchor="connection.management"/>
    <x:has anchor="differences.between.http.and.mime"/>
    <x:has anchor="field.parsing"/>
    <x:has anchor="h1.effective.request.uri"/>
    <x:has anchor="request.target"/>
    <x:has anchor="header.connection"/>
    <x:has anchor="header.fields"/>
    <x:has anchor="header.te"/>
    <x:has anchor="header.transfer-encoding"/>
    <x:has anchor="header.upgrade"/>
    <x:has anchor="http.message"/>
    <x:has anchor="media.type.message.http"/>
    <x:has anchor="line.folding"/>
    <x:has anchor="message.body"/>
    <x:has anchor="persistent.connections"/>
    <x:has anchor="persistent.tear-down"/>
    <x:has anchor="request.line"/>
    <x:has anchor="request.smuggling"/>
    <x:has anchor="status.line"/>
    <x:has anchor="transfer.codings"/>
    <x:has anchor="Messaging-acks" target="acks"/>
    <x:has anchor="Messaging-security.considerations" target="security.considerations"/>
  </x:source>
</reference>

<reference anchor="Caching">
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-&ID-VERSION;"/>
  <x:source href="draft-ietf-httpbis-cache-latest.xml" basename="draft-ietf-httpbis-cache-latest">
    <x:has anchor="cache-request-directive.no-store"/>
    <x:has anchor="cache-response-directive.private"/>
    <x:has anchor="caching.authenticated.responses"/>
    <x:has anchor="caching.negotiated.responses"/>
    <x:has anchor="caching.overview"/>
    <x:has anchor="calculating.freshness.lifetime"/>
    <x:has anchor="freshening.responses"/>
    <x:has anchor="head.effects"/>
    <x:has anchor="header.age"/>
    <x:has anchor="header.cache-control"/>
    <x:has anchor="header.expires"/>
    <x:has anchor="header.pragma"/>
    <x:has anchor="header.warning"/>
    <x:has anchor="heuristic.freshness"/>
    <x:has anchor="invalidation"/>
    <x:has anchor="validation.received"/>
    <x:has anchor="Caching-security.considerations" target="security.considerations"/>
  </x:source>
</reference>

<reference anchor="RFC2045">
  <front>
    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
    <author initials="N." surname="Freed" fullname="Ned Freed">
      <organization>Innosoft International, Inc.</organization>
      <address><email>ned@innosoft.com</email></address>
    </author>
    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
      <organization>First Virtual Holdings</organization>
      <address><email>nsb@nsb.fv.com</email></address>
    </author>
    <date month="November" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="2045"/>
</reference>

<reference anchor="RFC2046">
  <front>
    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
    <author initials="N." surname="Freed" fullname="Ned Freed">
      <organization>Innosoft International, Inc.</organization>
      <address><email>ned@innosoft.com</email></address>
    </author>
    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
      <organization>First Virtual Holdings</organization>
      <address><email>nsb@nsb.fv.com</email></address>
    </author>
    <date month="November" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="2046"/>
</reference>

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner">
      <organization>Harvard University</organization>
      <address><email>sob@harvard.edu</email></address>
    </author>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>

<reference anchor="RFC3986">
 <front>
  <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
  <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
    <address>
       <email>timbl@w3.org</email>
       <uri>http://www.w3.org/People/Berners-Lee/</uri>
    </address>
  </author>
  <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
    <organization abbrev="Day Software">Day Software</organization>
    <address>
      <email>fielding@gbiv.com</email>
      <uri>http://roy.gbiv.com/</uri>
    </address>
  </author>
  <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
    <organization>Adobe</organization>
    <address>
      <email>LMM@acm.org</email>
      <uri>http://larry.masinter.net/</uri>
    </address>
  </author>
  <date month='January' year='2005'></date>
 </front>
 <seriesInfo name="STD" value="66"/>
 <seriesInfo name="RFC" value="3986"/>
</reference>

<reference anchor="RFC0793">
  <front>
    <title>Transmission Control Protocol</title>
    <author initials='J.' surname='Postel' fullname='Jon Postel'>
      <organization>University of Southern California (USC)/Information Sciences Institute</organization>
    </author>
    <date year='1981' month='September' />
  </front>
  <seriesInfo name='STD' value='7' />
  <seriesInfo name='RFC' value='793' />
</reference>

<reference anchor='RFC4647'>
  <front>
    <title>Matching of Language Tags</title>
    <author initials='A.' surname='Phillips' fullname='Addison Phillips' role="editor">
      <organization>Yahoo! Inc.</organization>
      <address><email>addison@inter-locale.com</email></address>
    </author>
    <author initials='M.' surname='Davis' fullname='Mark Davis' role="editor">
      <organization>Google</organization>
      <address><email>mark.davis@macchiato.com</email></address>
    </author>
    <date year='2006' month='September' />
  </front>
  <seriesInfo name='BCP' value='47' />
  <seriesInfo name='RFC' value='4647' />
</reference>

<reference anchor="RFC4648">
  <front>
    <title>The Base16, Base32, and Base64 Data Encodings</title>
    <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
    <date year="2006" month="October"/>
  </front>
  <seriesInfo value="4648" name="RFC"/>
</reference>

<reference anchor="RFC5234">
  <front>
    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
      <organization>Brandenburg InternetWorking</organization>
      <address>
        <email>dcrocker@bbiw.net</email>
      </address>  
    </author>
    <author initials="P." surname="Overell" fullname="Paul Overell">
      <organization>THUS plc.</organization>
      <address>
        <email>paul.overell@thus.net</email>
      </address>
    </author>
    <date month="January" year="2008"/>
  </front>
  <seriesInfo name="STD" value="68"/>
  <seriesInfo name="RFC" value="5234"/>
</reference>

<reference anchor='RFC5646'>
  <front>
    <title>Tags for Identifying Languages</title>
    <author initials='A.' surname='Phillips' fullname='Addison Phillips' role='editor'>
      <organization>Lab126</organization>
      <address><email>addison@inter-locale.com</email></address>
    </author>
    <author initials='M.' surname='Davis' fullname='Mark Davis' role='editor'>
      <organization>Google</organization>
      <address><email>mark.davis@google.com</email></address>
    </author>
    <date month='September' year='2009' />
  </front>
  <seriesInfo name='BCP' value='47' />
  <seriesInfo name='RFC' value='5646' />
</reference>

<reference anchor='RFC6365'>
  <front>
    <title>Terminology Used in Internationalization in the IETF</title>
    <author initials='P.' surname='Hoffman' fullname='P. Hoffman'/>
    <author initials='J.' surname='Klensin' fullname='J. Klensin'/>
    <date year='2011' month='September' />
  </front>
  <seriesInfo name='BCP' value='166' />
  <seriesInfo name='RFC' value='6365' />
</reference>

<reference anchor="USASCII">
  <front>
    <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
    <author>
      <organization>American National Standards Institute</organization>
    </author>
    <date year="1986"/>
  </front>
  <seriesInfo name="ANSI" value="X3.4"/>
</reference>

<reference anchor="RFC1950">
  <front>
    <title>ZLIB Compressed Data Format Specification version 3.3</title>
    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
      <organization>Aladdin Enterprises</organization>
      <address><email>ghost@aladdin.com</email></address>
    </author>
    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/>
    <date month="May" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="1950"/>
</reference>

<reference anchor="RFC1951">
  <front>
    <title>DEFLATE Compressed Data Format Specification version 1.3</title>
    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
      <organization>Aladdin Enterprises</organization>
      <address><email>ghost@aladdin.com</email></address>
    </author>
    <date month="May" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="1951"/>
</reference>

<reference anchor="RFC1952">
  <front>
    <title>GZIP file format specification version 4.3</title>
    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
      <organization>Aladdin Enterprises</organization>
      <address><email>ghost@aladdin.com</email></address>
    </author>
    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
      <address><email>gzip@prep.ai.mit.edu</email></address>
    </author>
    <author initials="M." surname="Adler" fullname="Mark Adler">
      <address><email>madler@alumni.caltech.edu</email></address>
    </author>
    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
      <address><email>ghost@aladdin.com</email></address>
    </author>
    <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">
      <address><email>randeg@alumni.rpi.edu</email></address>
    </author>
    <date month="May" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="1952"/>
</reference>

<reference anchor="Welch">
  <front>
    <title>A Technique for High-Performance Data Compression</title>
    <author initials="T. A." surname="Welch" fullname="Terry A. Welch"/>
    <date month="June" year="1984"/>
  </front>
  <seriesInfo name="IEEE Computer" value="17(6)"/>
</reference>

</references>

<references title="Informative References">

<reference anchor="Georgiev" target="http://doi.acm.org/10.1145/2382196.2382204">
  <front>
    <title>The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software</title>
    <author initials="M." surname="Georgiev" fullname="Martin Georgiev"/>
    <author initials="S." surname="Iyengar" fullname="Subodh Iyengar"/>
    <author initials="S." surname="Jana" fullname="Suman Jana"/>
    <author initials="R." surname="Anubhai" fullname="Rishita Anubhai"/>
    <author initials="D." surname="Boneh" fullname="Dan Boneh"/>
    <author initials="V." surname="Shmatikov" fullname="Vitaly Shmatikov"/>
    <date year="2012" month="October"/>
  </front>
  <refcontent>In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49</refcontent>
</reference>

<reference anchor="ISO-8859-1">
  <front>
    <title>
     Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1
    </title>
    <author>
      <organization>International Organization for Standardization</organization>
    </author>
    <date year="1998"/>
  </front>
  <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
</reference>

<reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/0105018">
  <front>
    <title>HTTP Cookies: Standards, Privacy, and Politics</title>
    <author initials="D." surname="Kristol" fullname="David M. Kristol"/>
    <date year="2001" month="November"/>
  </front>
  <seriesInfo name="ACM Transactions on Internet Technology" value="1(2)"/>
</reference>

<reference anchor="REST" target="https://roy.gbiv.com/pubs/dissertation/top.htm">
  <front>
    <title>Architectural Styles and the Design of Network-based Software Architectures</title>
    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
    </author>
    <date month="September" year="2000"/>
  </front>
  <refcontent>Doctoral Dissertation, University of California, Irvine</refcontent>
</reference>

<reference anchor='RFC1919'>
  <front>
    <title>Classical versus Transparent IP Proxies</title>
    <author initials='M.' surname='Chatel' fullname='Marc Chatel'>
      <address><email>mchatel@pax.eunet.ch</email></address>
    </author>
    <date year='1996' month='March' />
  </front>
  <seriesInfo name='RFC' value='1919' />
</reference>

<reference anchor="RFC1945">
  <front>
    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization>MIT, Laboratory for Computer Science</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <date month="May" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="1945"/>
</reference>

<reference anchor="RFC2047">
  <front>
    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
    <author initials="K." surname="Moore" fullname="Keith Moore">
      <organization>University of Tennessee</organization>
      <address><email>moore@cs.utk.edu</email></address>
    </author>
    <date month="November" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="2047"/>
</reference>

<reference anchor="RFC2068">
  <front>
    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>jg@w3.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
      <address><email>mogul@wrl.dec.com</email></address>
    </author>
    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <date month="January" year="1997"/>
  </front>
  <seriesInfo name="RFC" value="2068"/>
</reference>

<reference anchor="RFC2145">
  <front>
    <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization>Western Research Laboratory</organization>
      <address><email>mogul@wrl.dec.com</email></address>
    </author>
    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
      <organization>Department of Information and Computer Science</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>jg@w3.org</email></address>
    </author>
    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
      <organization>W3 Consortium</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <date month="May" year="1997"/>
  </front>
  <seriesInfo name="RFC" value="2145"/>
</reference>

<reference anchor='RFC2295'>
  <front>
    <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title>
    <author initials='K.' surname='Holtman' fullname='Koen Holtman'>
      <organization>Technische Universiteit Eindhoven</organization>
      <address>
        <email>koen@win.tue.nl</email>
      </address>
    </author>
    <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'>
      <organization>Hewlett-Packard Company</organization>
      <address>
        <email>mutz@hpl.hp.com</email>
      </address>
    </author>
    <date year='1998' month='March'/>
  </front>
  <seriesInfo name='RFC' value='2295'/>
</reference>

<reference anchor="RFC2388">
  <front>
    <title abbrev="multipart/form-data">Returning Values from Forms:  multipart/form-data</title>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization>Xerox Palo Alto Research Center</organization>
      <address><email>masinter@parc.xerox.com</email></address>
    </author>
    <date year="1998" month="August"/>
  </front>
  <seriesInfo name="RFC" value="2388"/>
</reference>

<reference anchor="RFC2557">
  <front>
    <title abbrev="MIME Encapsulation of Aggregate Documents">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
    <author initials="F." surname="Palme" fullname="Jacob Palme">
      <organization>Stockholm University and KTH</organization>
      <address><email>jpalme@dsv.su.se</email></address>
    </author>
    <author initials="A." surname="Hopmann" fullname="Alex Hopmann">
      <organization>Microsoft Corporation</organization>
      <address><email>alexhop@microsoft.com</email></address>
    </author>
    <author initials="N." surname="Shelness" fullname="Nick Shelness">
      <organization>Lotus Development Corporation</organization>
      <address><email>Shelness@lotus.com</email></address>
    </author>
    <author initials="E." surname="Stefferud" fullname="Einar Stefferud">
      <address><email>stef@nma.com</email></address>
    </author>
    <date year="1999" month="March"/>
  </front>
  <seriesInfo name="RFC" value="2557"/>
</reference>

<reference anchor="RFC2616">
  <front>
    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
    <author initials="R." surname="Fielding" fullname="R. Fielding">
      <organization>University of California, Irvine</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="J. Gettys">
      <organization>W3C</organization>
      <address><email>jg@w3.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="J. Mogul">
      <organization>Compaq Computer Corporation</organization>
      <address><email>mogul@wrl.dec.com</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="L. Masinter">
      <organization>Xerox Corporation</organization>
      <address><email>masinter@parc.xerox.com</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="P. Leach">
      <organization>Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
      <organization>W3C</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <date month="June" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2616"/>
</reference>

<reference anchor="RFC2617">
  <front>
    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
    <author initials="J." surname="Franks" fullname="John Franks">
      <organization>Northwestern University, Department of Mathematics</organization>
      <address><email>john@math.nwu.edu</email></address>
    </author>
    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
      <organization>Verisign Inc.</organization>
      <address><email>pbaker@verisign.com</email></address>
    </author>
    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
      <organization>AbiSource, Inc.</organization>
      <address><email>jeff@AbiSource.com</email></address>
    </author>
    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
      <organization>Agranat Systems, Inc.</organization>
      <address><email>lawrence@agranat.com</email></address>
    </author>
    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
      <organization>Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
      <organization>Netscape Communications Corporation</organization>
    </author>
    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
      <organization>Open Market, Inc.</organization>
      <address><email>stewart@OpenMarket.com</email></address>
    </author>
    <date month="June" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2617"/>
</reference>

<reference anchor='RFC2774'>
  <front>
    <title>An HTTP Extension Framework</title>
    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
      <address><email>frystyk@w3.org</email></address>
    </author>
    <author initials='P.' surname='Leach' fullname='Paul J. Leach'>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials='S.' surname='Lawrence' fullname='Scott Lawrence'>
      <address><email>lawrence@agranat.com</email></address>
    </author>
    <date year='2000' month='February' />
  </front>
  <seriesInfo name='RFC' value='2774' />
</reference>

<reference anchor='RFC2818'>
  <front>
    <title>HTTP Over TLS</title>
    <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
      <organization>RTFM, Inc.</organization>
      <address><email>ekr@rtfm.com</email></address>
    </author>
    <date year='2000' month='May' />
  </front>
  <seriesInfo name='RFC' value='2818' />
</reference>

<reference anchor='RFC2978'>
  <front>
    <title>IANA Charset Registration Procedures</title>
    <author initials='N.' surname='Freed' fullname='N. Freed'/>
    <author initials='J.' surname='Postel' fullname='J. Postel'/>
    <date year='2000' month='October' />
  </front>
   <seriesInfo name='BCP' value='19' />
   <seriesInfo name='RFC' value='2978' />
</reference>

<reference anchor='RFC3040'>
  <front>
    <title>Internet Web Replication and Caching Taxonomy</title>
    <author initials='I.' surname='Cooper' fullname='I. Cooper'>
      <organization>Equinix, Inc.</organization>
    </author>
    <author initials='I.' surname='Melve' fullname='I. Melve'>
      <organization>UNINETT</organization>
    </author>
    <author initials='G.' surname='Tomlinson' fullname='G. Tomlinson'>
      <organization>CacheFlow Inc.</organization>
    </author>
    <date year='2001' month='January' />
  </front>
  <seriesInfo name='RFC' value='3040' />
</reference>

<reference anchor='RFC4033'>
  <front>
    <title>DNS Security Introduction and Requirements</title>
    <author initials='R.' surname='Arends' fullname='R. Arends'/>
    <author initials='R.' surname='Austein' fullname='R. Austein'/>
    <author initials='M.' surname='Larson' fullname='M. Larson'/>
    <author initials='D.' surname='Massey' fullname='D. Massey'/>
    <author initials='S.' surname='Rose' fullname='S. Rose'/>
    <date year='2005' month='March' />
  </front>
  <seriesInfo name='RFC' value='4033' />
</reference>

<reference anchor='RFC4559'>
  <front>
    <title>SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
    <author initials='K.' surname='Jaganathan' fullname='K. Jaganathan'/>
    <author initials='L.' surname='Zhu' fullname='L. Zhu'/>
    <author initials='J.' surname='Brezak' fullname='J. Brezak'/>
    <date year='2006' month='June' />
  </front>
  <seriesInfo name='RFC' value='4559' />
</reference>

<reference anchor='RFC4918'>
  <front>
    <title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title>
    <author initials="L.M." surname="Dusseault" fullname="Lisa Dusseault" role="editor" >
      <organization abbrev="CommerceNet">CommerceNet</organization>
      <address><email>ldusseault@commerce.net</email></address>
    </author>
    <date month="June" year="2007" />
  </front>
  <seriesInfo name='RFC' value='4918' />
</reference>

<reference anchor='RFC5246'>
   <front>
      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
      <author initials='T.' surname='Dierks' fullname='T. Dierks'/>
      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
         <organization>RTFM, Inc.</organization>
      </author>
      <date year='2008' month='August' />
   </front>
   <seriesInfo name='RFC' value='5246' />
</reference>

<reference anchor='RFC5905'>
  <front>
    <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
    <author initials='D.' surname='Mills' fullname='David L. Mills'/>
    <author initials='J.' surname='Martin' fullname='Jim Martin' role="editor"/>
    <author initials='J.' surname='Burbank' fullname='Jack Burbank'/>
    <author initials='W.' surname='Kasch' fullname='William Kasch'/>
    <date year='2010' month='June' />
  </front>
  <seriesInfo name='RFC' value='5905' />
</reference>

<reference anchor="RFC7230">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization>Adobe</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7230"/>
</reference>

<reference anchor="RFC7231">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization>Adobe</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7231"/>
</reference>

<reference anchor="RFC7232">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
      <organization>Adobe</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014" />
  </front>
  <seriesInfo name="RFC" value="7232"/>
</reference>

<reference anchor="RFC7233">
  <front>
    <title>Hypertext Transfer Protocol (HTTP): Range Requests</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization>Adobe</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7233"/>
</reference>

<reference anchor="RFC7235">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization>Adobe</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7235"/>
</reference>

<reference anchor="BCP13">
  <front>
    <title>Media Type Specifications and Registration Procedures</title>
    <author initials="N." surname="Freed" fullname="Ned Freed">
      <organization>Oracle</organization>
      <address>
        <email>ned+ietf@mrochek.com</email>
      </address>
    </author>
    <author initials="J." surname="Klensin" fullname="John C. Klensin">
      <address>
        <email>john+ietf@jck.com</email>
      </address>
    </author>
    <author initials="T." surname="Hansen" fullname="Tony Hansen">
      <organization>AT&amp;T Laboratories</organization>
      <address>
        <email>tony+mtsuffix@maillennium.att.com</email>
      </address>
    </author>
    <date year="2013" month="January"/>
  </front>
  <seriesInfo name="BCP" value="13"/>
  <seriesInfo name="RFC" value="6838"/>
</reference>

<reference anchor='BCP90'>
  <front>
    <title>Registration Procedures for Message Header Fields</title>
    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
      <organization>Nine by Nine</organization>
      <address><email>GK-IETF@ninebynine.org</email></address>
    </author>
    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
      <organization>BEA Systems</organization>
      <address><email>mnot@pobox.com</email></address>
    </author>
    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
      <organization>HP Labs</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <date year='2004' month='September' />
  </front>
  <seriesInfo name='BCP' value='90' />
  <seriesInfo name='RFC' value='3864' />
</reference>

<reference anchor='BCP115'>
  <front>
    <title>Guidelines and Registration Procedures for New URI Schemes</title>
    <author initials='T.' surname='Hansen' fullname='T. Hansen'>
      <organization>AT&amp;T Laboratories</organization>
      <address>
        <email>tony+urireg@maillennium.att.com</email>
      </address>
    </author>
    <author initials='T.' surname='Hardie' fullname='T. Hardie'>
      <organization>Qualcomm, Inc.</organization>
      <address>
        <email>hardie@qualcomm.com</email>
      </address>
    </author>
    <author initials='L.' surname='Masinter' fullname='L. Masinter'>
      <organization>Adobe</organization>
      <address>
        <email>LMM@acm.org</email>
      </address>
    </author>
    <date year='2006' month='February' />
  </front>
  <seriesInfo name='BCP' value='115' />
  <seriesInfo name='RFC' value='4395' />
</reference>

<reference anchor="BCP178">
  <front>
    <title>Deprecating the "X-" Prefix and Similar Constructs in Application Protocols</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre"/>
    <author initials="D." surname="Crocker" fullname="Dave Crocker"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham"/>
    <date year="2012" month="June"/>
  </front>
  <seriesInfo name="BCP" value="178"/>
  <seriesInfo name="RFC" value="6648"/>
</reference>

<reference anchor="RFC5322">
  <front>
    <title>Internet Message Format</title>
    <author initials="P." surname="Resnick" fullname="P. Resnick">
      <organization>Qualcomm Incorporated</organization>
    </author>
    <date year="2008" month="October"/>
  </front> 
  <seriesInfo name="RFC" value="5322"/>
</reference>

<reference anchor='RFC5789'>
  <front>
    <title>PATCH Method for HTTP</title>
    <author initials='L.' surname='Dusseault' fullname='L. Dusseault'>
      <organization>Linden Lab</organization>
    </author>
    <author initials='J.' surname='Snell' fullname='J. Snell' />
    <date year='2010' month='March' />
  </front>
  <seriesInfo name='RFC' value='5789' />
</reference>

<reference anchor="RFC5987">
	<front>
    <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address>
        <postal>
          <street>Hafenweg 16</street>
          <city>Muenster</city><region>NW</region><code>48155</code>
          <country>Germany</country>
        </postal>
        <email>julian.reschke@greenbytes.de</email>
        <uri>http://greenbytes.de/tech/webdav/</uri>
      </address>
    </author>
    <date month="August" year="2010"/>
  </front>
  <seriesInfo name="RFC" value="5987"/>
</reference>

<reference anchor='RFC5988'>
  <front>
    <title>Web Linking</title>
    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'/>
    <date year='2010' month='October' />
  </front>
  <seriesInfo name='RFC' value='5988' />
</reference>

<reference anchor="RFC6265">
  <front>
    <title>HTTP State Management Mechanism</title>
    <author initials="A." surname="Barth" fullname="Adam Barth">
      <organization abbrev="U.C. Berkeley">
        University of California, Berkeley
      </organization>
      <address><email>abarth@eecs.berkeley.edu</email></address>
    </author>
    <date year="2011" month="April" />
  </front>
  <seriesInfo name="RFC" value="6265"/>
</reference>

<reference anchor='RFC6585'>
  <front>
    <title>Additional HTTP Status Codes</title>
    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
      <organization>Rackspace</organization>
    </author>
    <author initials='R.' surname='Fielding' fullname='R. Fielding'>
      <organization>Adobe</organization>
    </author>
    <date year='2012' month='April' />
   </front>
   <seriesInfo name='RFC' value='6585' />
</reference>

<reference anchor="RFC7238">
	<front>
    <title>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</title>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address>
        <email>julian.reschke@greenbytes.de</email>
      </address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7238"/>
</reference>

<reference anchor='RFC7616'>
  <front>
    <title>HTTP Digest Access Authentication</title>
    <author initials='R.' surname='Shekh-Yusef' fullname='R. Shekh-Yusef' role='editor'>
      <organization>Avaya</organization>
    </author>
    <author initials='D.' surname='Ahrens' fullname='D. Ahrens'>
      <organization />
    </author>
    <author initials='S.' surname='Bremer' fullname='S. Bremer'>
      <organization>Netzkonform</organization>
    </author>
    <date year='2015' month='September' />
  </front>
  <seriesInfo name='RFC' value='7616'/>
</reference>

<reference anchor='RFC7617'>
  <front>
    <title>The 'Basic' HTTP Authentication Scheme</title>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address>
        <email>julian.reschke@greenbytes.de</email>
      </address>
    </author>
    <date year='2015' month='September' />
  </front>
  <seriesInfo name='RFC' value='7617'/>
</reference>

<reference anchor="RFC8126">
  <front>
    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
    <author initials="M." surname="Cotton" fullname="M. Cotton"/>
    <author initials="B." surname="Leiba" fullname="B. Leiba"/>
    <author initials="T." surname="Narten" fullname="T. Narten"/>
    <date year="2017" month="June" />
  </front>
  <seriesInfo name="BCP" value="26"/>
  <seriesInfo name="RFC" value="8126"/>
</reference>

<reference anchor="OWASP" target="https://www.owasp.org/">
	<front>
    <title abbrev="OWASP">A Guide to Building Secure Web Applications and Web Services</title>
    <author role="editor" initials="A." surname="van der Stock"
            fullname="Andrew van der Stock"/>
    <date month="July" day="27" year="2005"/>
  </front>
  <seriesInfo name="The Open Web Application Security Project (OWASP)" value="2.0.1"/>
</reference>
</references>

<?BEGININC build/draft-ietf-httpbis-semantics-latest.abnf-appendix ?>
<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
<t>In the collected ABNF below, list rules are expanded as per <xref target="abnf.extension"/>.</t><figure>
<artwork type="abnf" name="draft-ietf-httpbis-semantics-latest.parsed-abnf">
<x:ref>Accept</x:ref> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
 OWS ( media-range [ accept-params ] ) ] ) ]
<x:ref>Accept-Charset</x:ref> = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
 "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
<x:ref>Accept-Encoding</x:ref> = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
 ( codings [ weight ] ) ] ) ]
<x:ref>Accept-Language</x:ref> = *( "," OWS ) ( language-range [ weight ] ) *( OWS
 "," [ OWS ( language-range [ weight ] ) ] )
<x:ref>Accept-Ranges</x:ref> = acceptable-ranges
<x:ref>Allow</x:ref> = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
<x:ref>Authorization</x:ref> = credentials

<x:ref>BWS</x:ref> = OWS

<x:ref>Content-Encoding</x:ref> = *( "," OWS ) content-coding *( OWS "," [ OWS
 content-coding ] )
<x:ref>Content-Language</x:ref> = *( "," OWS ) language-tag *( OWS "," [ OWS
 language-tag ] )
<x:ref>Content-Length</x:ref> = 1*DIGIT
<x:ref>Content-Location</x:ref> = absolute-URI / partial-URI
<x:ref>Content-Range</x:ref> = byte-content-range / other-content-range
<x:ref>Content-Type</x:ref> = media-type

<x:ref>Date</x:ref> = HTTP-date

<x:ref>ETag</x:ref> = entity-tag
<x:ref>Expect</x:ref> = "100-continue"

<x:ref>From</x:ref> = mailbox

<x:ref>GMT</x:ref> = %x47.4D.54 ; GMT

<x:ref>HTTP-date</x:ref> = IMF-fixdate / obs-date
<x:ref>Host</x:ref> = uri-host [ ":" port ]

<x:ref>IMF-fixdate</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
<x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
 entity-tag ] ) )
<x:ref>If-Modified-Since</x:ref> = HTTP-date
<x:ref>If-None-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
 entity-tag ] ) )
<x:ref>If-Range</x:ref> = entity-tag / HTTP-date
<x:ref>If-Unmodified-Since</x:ref> = HTTP-date

<x:ref>Last-Modified</x:ref> = HTTP-date
<x:ref>Location</x:ref> = URI-reference

<x:ref>Max-Forwards</x:ref> = 1*DIGIT

<x:ref>OWS</x:ref> = *( SP / HTAB )

<x:ref>Proxy-Authenticate</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS
 challenge ] )
<x:ref>Proxy-Authorization</x:ref> = credentials

<x:ref>RWS</x:ref> = 1*( SP / HTAB )
<x:ref>Range</x:ref> = byte-ranges-specifier / other-ranges-specifier
<x:ref>Referer</x:ref> = absolute-URI / partial-URI
<x:ref>Retry-After</x:ref> = HTTP-date / delay-seconds

<x:ref>Server</x:ref> = product *( RWS ( product / comment ) )

<x:ref>Trailer</x:ref> = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )

<x:ref>URI-reference</x:ref> = &lt;URI-reference, see <xref target="RFC3986" x:fmt="," x:sec="4.1"/>&gt;
<x:ref>User-Agent</x:ref> = product *( RWS ( product / comment ) )

<x:ref>Vary</x:ref> = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
 ) )
<x:ref>Via</x:ref> = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
 ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
 comment ] ) ] )

<x:ref>WWW-Authenticate</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS challenge
 ] )

<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, see <xref target="RFC3986" x:fmt="," x:sec="4.3"/>&gt;
<x:ref>absolute-path</x:ref> = 1*( "/" segment )
<x:ref>accept-ext</x:ref> = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
<x:ref>accept-params</x:ref> = weight *accept-ext
<x:ref>acceptable-ranges</x:ref> = ( *( "," OWS ) range-unit *( OWS "," [ OWS
 range-unit ] ) ) / "none"
<x:ref>asctime-date</x:ref> = day-name SP date3 SP time-of-day SP year
<x:ref>auth-param</x:ref> = token BWS "=" BWS ( token / quoted-string )
<x:ref>auth-scheme</x:ref> = token
<x:ref>authority</x:ref> = &lt;authority, see <xref target="RFC3986" x:fmt="," x:sec="3.2"/>&gt;

<x:ref>byte-content-range</x:ref> = bytes-unit SP ( byte-range-resp /
 unsatisfied-range )
<x:ref>byte-range</x:ref> = first-byte-pos "-" last-byte-pos
<x:ref>byte-range-resp</x:ref> = byte-range "/" ( complete-length / "*" )
<x:ref>byte-range-set</x:ref> = *( "," OWS ) ( byte-range-spec /
 suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
 suffix-byte-range-spec ) ] )
<x:ref>byte-range-spec</x:ref> = first-byte-pos "-" [ last-byte-pos ]
<x:ref>byte-ranges-specifier</x:ref> = bytes-unit "=" byte-range-set
<x:ref>bytes-unit</x:ref> = "bytes"

<x:ref>challenge</x:ref> = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
 OWS "," [ OWS auth-param ] ) ] ) ]
<x:ref>charset</x:ref> = token
<x:ref>codings</x:ref> = content-coding / "identity" / "*"
<x:ref>comment</x:ref> = "(" *( ctext / quoted-pair / comment ) ")"
<x:ref>complete-length</x:ref> = 1*DIGIT
<x:ref>content-coding</x:ref> = token
<x:ref>credentials</x:ref> = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
 *( OWS "," [ OWS auth-param ] ) ] ) ]
<x:ref>ctext</x:ref> = HTAB / SP / %x21-27 ; '!'-'''
 / %x2A-5B ; '*'-'['
 / %x5D-7E ; ']'-'~'
 / obs-text

<x:ref>date1</x:ref> = day SP month SP year
<x:ref>date2</x:ref> = day "-" month "-" 2DIGIT
<x:ref>date3</x:ref> = month SP ( 2DIGIT / ( SP DIGIT ) )
<x:ref>day</x:ref> = 2DIGIT
<x:ref>day-name</x:ref> = %x4D.6F.6E ; Mon
 / %x54.75.65 ; Tue
 / %x57.65.64 ; Wed
 / %x54.68.75 ; Thu
 / %x46.72.69 ; Fri
 / %x53.61.74 ; Sat
 / %x53.75.6E ; Sun
<x:ref>day-name-l</x:ref> = %x4D.6F.6E.64.61.79 ; Monday
 / %x54.75.65.73.64.61.79 ; Tuesday
 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
 / %x54.68.75.72.73.64.61.79 ; Thursday
 / %x46.72.69.64.61.79 ; Friday
 / %x53.61.74.75.72.64.61.79 ; Saturday
 / %x53.75.6E.64.61.79 ; Sunday
<x:ref>delay-seconds</x:ref> = 1*DIGIT

<x:ref>entity-tag</x:ref> = [ weak ] opaque-tag
<x:ref>etagc</x:ref> = "!" / %x23-7E ; '#'-'~'
 / obs-text

<x:ref>field-content</x:ref> = field-vchar [ 1*( SP / HTAB ) field-vchar ]
<x:ref>field-name</x:ref> = token
<x:ref>field-value</x:ref> = *( field-content / obs-fold )
<x:ref>field-vchar</x:ref> = VCHAR / obs-text
<x:ref>first-byte-pos</x:ref> = 1*DIGIT
<x:ref>fragment</x:ref> = &lt;fragment, see <xref target="RFC3986" x:fmt="," x:sec="3.5"/>&gt;

<x:ref>hour</x:ref> = 2DIGIT
<x:ref>http-URI</x:ref> = "http://" authority path-abempty [ "?" query ] [ "#"
 fragment ]
<x:ref>https-URI</x:ref> = "https://" authority path-abempty [ "?" query ] [ "#"
 fragment ]

<x:ref>language-range</x:ref> = &lt;language-range, see <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
<x:ref>language-tag</x:ref> = &lt;Language-Tag, see <xref target="RFC5646" x:fmt="," x:sec="2.1"/>&gt;
<x:ref>last-byte-pos</x:ref> = 1*DIGIT

<x:ref>mailbox</x:ref> = &lt;mailbox, see <xref target="RFC5322" x:fmt="," x:sec="3.4"/>&gt;
<x:ref>media-range</x:ref> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
 ";" OWS parameter )
<x:ref>media-type</x:ref> = type "/" subtype *( OWS ";" OWS parameter )
<x:ref>method</x:ref> = token
<x:ref>minute</x:ref> = 2DIGIT
<x:ref>month</x:ref> = %x4A.61.6E ; Jan
 / %x46.65.62 ; Feb
 / %x4D.61.72 ; Mar
 / %x41.70.72 ; Apr
 / %x4D.61.79 ; May
 / %x4A.75.6E ; Jun
 / %x4A.75.6C ; Jul
 / %x41.75.67 ; Aug
 / %x53.65.70 ; Sep
 / %x4F.63.74 ; Oct
 / %x4E.6F.76 ; Nov
 / %x44.65.63 ; Dec

<x:ref>obs-date</x:ref> = rfc850-date / asctime-date
<x:ref>obs-fold</x:ref> = &lt;obs-fold, see <xref target="Messaging" x:fmt="," x:sec="5.2"/>&gt;
<x:ref>obs-text</x:ref> = %x80-FF
<x:ref>opaque-tag</x:ref> = DQUOTE *etagc DQUOTE
<x:ref>other-content-range</x:ref> = other-range-unit SP other-range-resp
<x:ref>other-range-resp</x:ref> = *CHAR
<x:ref>other-range-set</x:ref> = 1*VCHAR
<x:ref>other-range-unit</x:ref> = token
<x:ref>other-ranges-specifier</x:ref> = other-range-unit "=" other-range-set

<x:ref>parameter</x:ref> = token "=" ( token / quoted-string )
<x:ref>partial-URI</x:ref> = relative-part [ "?" query ]
<x:ref>path-abempty</x:ref> = &lt;path-abempty, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
<x:ref>port</x:ref> = &lt;port, see <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>&gt;
<x:ref>product</x:ref> = token [ "/" product-version ]
<x:ref>product-version</x:ref> = token
<x:ref>protocol-name</x:ref> = &lt;protocol-name, see <xref target="Messaging" x:fmt="," x:sec="9.7"/>&gt;
<x:ref>protocol-version</x:ref> = &lt;protocol-version, see <xref target="Messaging" x:fmt="," x:sec="9.7"/>&gt;
<x:ref>pseudonym</x:ref> = token

<x:ref>qdtext</x:ref> = HTAB / SP / "!" / %x23-5B ; '#'-'['
 / %x5D-7E ; ']'-'~'
 / obs-text
<x:ref>query</x:ref> = &lt;query, see <xref target="RFC3986" x:fmt="," x:sec="3.4"/>&gt;
<x:ref>quoted-pair</x:ref> = "\" ( HTAB / SP / VCHAR / obs-text )
<x:ref>quoted-string</x:ref> = DQUOTE *( qdtext / quoted-pair ) DQUOTE
<x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )

<x:ref>range-unit</x:ref> = bytes-unit / other-range-unit
<x:ref>received-by</x:ref> = ( uri-host [ ":" port ] ) / pseudonym
<x:ref>received-protocol</x:ref> = [ protocol-name "/" ] protocol-version
<x:ref>relative-part</x:ref> = &lt;relative-part, see <xref target="RFC3986" x:fmt="," x:sec="4.2"/>&gt;
<x:ref>request-target</x:ref> = &lt;request-target, see <xref target="Messaging" x:fmt="," x:sec="3.2"/>&gt;
<x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT

<x:ref>second</x:ref> = 2DIGIT
<x:ref>segment</x:ref> = &lt;segment, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
<x:ref>subtype</x:ref> = token
<x:ref>suffix-byte-range-spec</x:ref> = "-" suffix-length
<x:ref>suffix-length</x:ref> = 1*DIGIT

<x:ref>tchar</x:ref> = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*" / "+" / "-" / "." /
 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
<x:ref>time-of-day</x:ref> = hour ":" minute ":" second
<x:ref>token</x:ref> = 1*tchar
<x:ref>token68</x:ref> = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
 *"="
<x:ref>type</x:ref> = token

<x:ref>unsatisfied-range</x:ref> = "*/" complete-length
<x:ref>uri-host</x:ref> = &lt;host, see <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>&gt;

<x:ref>weak</x:ref> = %x57.2F ; W/
<x:ref>weight</x:ref> = OWS ";" OWS "q=" qvalue

<x:ref>year</x:ref> = 4DIGIT
</artwork>
</figure>
</section>
<?ENDINC build/draft-ietf-httpbis-semantics-latest.abnf-appendix ?>

<section title="Changes from RFC 7230" anchor="changes.from.rfc.7230">
<t>
  Most of the sections introducing HTTP's design goals, history, architecture,
  conformance criteria, protocol versioning, URIs, message routing, and
  header field values have been moved here (without substantive change).
</t>
</section>

<section title="Changes from RFC 7231" anchor="changes.from.rfc.7231">
<t>
   None yet.
</t>
</section>

<section title="Changes from RFC 7232" anchor="changes.from.rfc.7232">
<t>
   None yet.
</t>
</section>

<section title="Changes from RFC 7233" anchor="changes.from.rfc.7233">
<t>
   None yet.
</t>
</section>

<section title="Changes from RFC 7235" anchor="changes.from.rfc.7235">
<t>
   None yet.
</t>
</section>

<section title="Change Log" anchor="change.log" removeInRFC="true">

<section title="Between RFC723x and draft 00" anchor="changes.since.publication.as.rfc">
<t>
  The changes were purely editorial:
</t>
<ul>
  <li>Change boilerplate and abstract to indicate the "draft" status, and update references to ancestor specifications.</li>
  <li>Remove version "1.1" from document title, indicating that this specification applies to all HTTP versions.</li>
  <li>Adjust historical notes.</li>
  <li>Update links to sibling specifications.</li>
  <li>Replace sections listing changes from RFC 2616 by new empty sections referring to RFC 723x.</li>
  <li>Remove acknowledgements specific to RFC 723x.</li>
  <li>Move "Acknowledgements" to the very end and make them unnumbered.</li>
</ul>
</section>

<section title="Since draft-ietf-httpbis-semantics-00" anchor="changes.since.00">
<t>
  The changes in this draft are editorial, with respect to HTTP as a whole,
  to merge core HTTP semantics into this document:
</t>
<ul>
  <li>Merged introduction, architecture, conformance, and ABNF extensions from
      <xref target="RFC7230" format="none">RFC 7230 (Messaging)</xref>.</li>
  <li>Rearranged architecture to extract conformance, http(s) schemes, and
      protocol versioning into a separate major section.</li>
  <li>Moved discussion of MIME differences to <xref target="Messaging"/> since
      that is primarily concerned with transforming 1.1 messages.</li>
  <li>Merged entire content of <xref target="RFC7232" format="none">RFC 7232 (Conditional Requests)</xref>.</li>
  <li>Merged entire content of <xref target="RFC7233" format="none">RFC 7233 (Range Requests)</xref>.</li>
  <li>Merged entire content of <xref target="RFC7235" format="none">RFC 7235 (Auth Framework)</xref>.</li>
  <li>Moved all extensibility tips, registration procedures, and registry
      tables from the IANA considerations to normative sections, reducing the
      IANA considerations to just instructions that will be removed prior to
      publication as an RFC.</li>
</ul>
</section>

<section title="Since draft-ietf-httpbis-semantics-01" anchor="changes.since.01">
<ul>
  <li>Cite RFC 8126 instead of RFC 5226 (<eref target="https://github.com/httpwg/http-core/issues/75"/>)</li>
</ul>
</section>
</section>

<section title="Acknowledgments" anchor="acks" numbered="false">
<t>
   This edition of the HTTP specification builds on the many contributions that went into
   <xref target="RFC1945" format="none">RFC 1945</xref>,
   <xref target="RFC2068" format="none">RFC 2068</xref>,
   <xref target="RFC2145" format="none">RFC 2145</xref>, and
   <xref target="RFC2616" format="none">RFC 2616</xref>, including 
   substantial contributions made by the previous authors, editors, and
   Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
   Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
   Paul J. Leach, and Yves Lafon.
</t>
<t>
   See <xref target="RFC7230" x:fmt="of" x:sec="10"/> for further
   acknowledgements from prior revisions.
</t>
<t>
   In addition, this document has reincorporated the HTTP Authentication
   Framework, previously defined in
   <xref target="RFC7235" x:fmt="none">RFC 7235</xref> and
   <xref target="RFC2617" x:fmt="none">RFC 2617</xref>.
   We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler,
   Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart
   for their work on that specification.
   See <xref target="RFC2617" x:fmt="of" x:sec="6"/>
   for further acknowledgements.
</t>
<t>
  <cref anchor="newacks">New acks to be added here.</cref>
</t>
</section>
</back>
</rfc>