Changeset 966


Ignore:
Timestamp:
Jul 29, 2010, 11:12:22 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html, but needs appendix updates

Location:
draft-ietf-httpbis/latest
Files:
7 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r963 r966  
    858858      <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>&gt;
    859859  <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
    860 </pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>&gt;
    861   <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
     860</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
    862861</pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    863862  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
     
    877876      <div id="rfc.iref.u.1"></div>
    878877      <div id="rfc.iref.o.1"></div>
     878      <div id="rfc.iref.b.1"></div>
     879      <div id="rfc.iref.s.2"></div>
    879880      <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
    880881         same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the
    881882         program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
    882          to refer to the program that can originate authoritative responses to a request.
     883         to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
     884         "sender" to refer to whichever component sent a given message and the term "recipient" to refer to any component that receives
     885         the message.
    883886      </p>
    884887      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
     
    919922
    920923<span id="exbody">Hello World!
    921 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
     924</span></pre><div id="rfc.iref.i.1"></div>
     925      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    922926      <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
    923927         common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server,
     
    934938         at the same time that it is handling A's request.
    935939      </p>
    936       <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.1"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
     940      <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
    937941         all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions
    938942         in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent.
     
    946950      <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
    947951         the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
    948          services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested
     952         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target
    949953         resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the
    950954         client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
     
    11531157         might introduce security flaws due to the differing ways that such parsers interpret invalid characters.
    11541158      </p>
     1159      <p id="rfc.section.3.1.p.4">HTTP allows the set of defined header fields to be extended without changing the protocol version (see <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;10.1</a>). However, such fields might not be recognized by a downstream recipient and might be stripped by non-transparent intermediaries.
     1160         Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by transparent proxies and <em class="bcp14">SHOULD</em> be ignored by a recipient.
     1161      </p>
    11551162      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
    11561163      <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field
     
    13051312                 / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>
    13061313                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
    1307                  / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
     1314                 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
    13081315</pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    13091316         or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
    1310          them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
     1317         them to be general-header fields.
    13111318      </p>
    13121319      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="request" href="#request">Request</a></h1>
     
    13151322      </p>
    13161323      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
    1317                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    1318                    / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
    1319                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1324                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    13201325                  <a href="#core.rules" class="smpl">CRLF</a>
    13211326                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
     
    13471352</pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    13481353      </p>
    1349       <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1354      <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13501355      </p>
    13511356      <p id="rfc.section.4.1.2.p.10">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
     
    13791384      </div>
    13801385      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1381          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1386         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13821387      </p>
    13831388      <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
     
    14091414      </p>
    14101415      <div id="rfc.iref.e.1"></div>
     1416      <div id="rfc.iref.t.2"></div>
    14111417      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
    1412       <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the resource they are intended for; instead, the value needs to be inferred from the request-target, Host header and
    1413          other context. The result of this process is the "Effective Request URI".
    1414       </p>
    1415       <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the Effective Request URI is the request-target.</p>
    1416       <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective
    1417          Request URI is constructed by concatenating
     1418      <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection
     1419         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
     1420         by the effective request URI.
     1421      </p>
     1422      <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
     1423      <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the effective
     1424         request URI is constructed by concatenating
    14181425      </p>
    14191426      <p id="rfc.section.4.3.p.4"> </p>
     
    14291436      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>
    14301437      <div id="rfc.figure.u.40"></div>
    1431       <p>Example 1: the Effective Request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
     1438      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    14321439Host: www.example.org:8080
    14331440</pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
     
    14351442      </p>
    14361443      <div id="rfc.figure.u.41"></div>
    1437       <p>Example 2: the Effective Request URI for the message</p>  <pre class="text">GET * HTTP/1.1
     1444      <p>Example 2: the effective request URI for the message</p>  <pre class="text">GET * HTTP/1.1
    14381445Host: www.example.org
    14391446</pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
    14401447         thus "https://www.example.org".
    14411448      </p>
    1442       <p id="rfc.section.4.3.p.8">Effective Request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
     1449      <p id="rfc.section.4.3.p.8">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
    14431450      </p>
    14441451      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    14451452      <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    14461453      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
    1447                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
    1448                    / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
    1449                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1454                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    14501455                  <a href="#core.rules" class="smpl">CRLF</a>
    14511456                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
     
    14581463</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    14591464      <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
    1460          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     1465         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    14611466         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    14621467         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
     
    15881593      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
    15891594      <p id="rfc.section.6.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    1590          indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information
    1591          necessary for the recipient to verify that it has received the full message.
     1595         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary
     1596         for the recipient to verify that it has received the full message.
    15921597      </p>
    15931598      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     
    16061611  <a href="#chunked.encoding" class="smpl">chunk-ext-val</a>  = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#chunked.encoding" class="smpl">quoted-str-nf</a>
    16071612  <a href="#chunked.encoding" class="smpl">chunk-data</a>     = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets
    1608   <a href="#chunked.encoding" class="smpl">trailer-part</a>   = *( <a href="#abnf.dependencies" class="smpl">entity-header</a> <a href="#core.rules" class="smpl">CRLF</a> )
     1613  <a href="#chunked.encoding" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    16091614 
    16101615  <a href="#chunked.encoding" class="smpl">quoted-str-nf</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#chunked.encoding" class="smpl">qdtext-nf</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
     
    16951700         <li>Pointer to specification text</li>
    16961701      </ul>
    1697       <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
     1702      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
    16981703      </p>
    16991704      <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
     
    17141719      </p>
    17151720      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1716       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1721      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17171722         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17181723         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
     
    17781783      <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    17791784      </p>
    1780       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1785      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    17811786         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    17821787      </p>
     
    18461851         </p>
    18471852      </div>
    1848       <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
     1853      <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    18491854      </p>
    18501855      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     
    18621867      </p>
    18631868      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1864          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1869         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    18651870         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    18661871      </p>
     
    18891894      </p>
    18901895      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    1891       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1896      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    18921897         to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    18931898         be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
     
    18961901      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    18971902      <ul>
    1898          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    1899          </li>
    1900          <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     1903         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1904         </li>
     1905         <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    19011906         </li>
    19021907      </ul>
     
    19421947         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    19431948            an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
    1944             of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1949            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    19451950         </li>
    19461951      </ul>
     
    19881993      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    19891994      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
    1990       <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1991          receives the message.
    1992       </p>
    19931995      <div id="rfc.iref.c.11"></div>
    19941996      <div id="rfc.iref.h.6"></div>
     
    21012103      <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
    21022104      </p>
    2103       <div id="rfc.iref.t.2"></div>
     2105      <div id="rfc.iref.t.3"></div>
    21042106      <div id="rfc.iref.h.11"></div>
    21052107      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     
    21502152         is always acceptable.
    21512153      </p>
    2152       <div id="rfc.iref.t.3"></div>
     2154      <div id="rfc.iref.t.4"></div>
    21532155      <div id="rfc.iref.h.12"></div>
    21542156      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     
    21702172         <li>Trailer</li>
    21712173      </ul>
    2172       <div id="rfc.iref.t.4"></div>
     2174      <div id="rfc.iref.t.5"></div>
    21732175      <div id="rfc.iref.h.13"></div>
    21742176      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    21752177      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
    2176          It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
     2178         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    21772179         are not.
    21782180      </p>
     
    21832185      </p>
    21842186      <div id="rfc.figure.u.71"></div><pre class="text">  Transfer-Encoding: chunked
    2185 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
     2187</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    21862188      </p>
    21872189      <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>
     
    28662868      </p>
    28672869      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
    2868          not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2870         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    28692871      </p>
    28702872      <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
     
    30083010<a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP )
    30093011<a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( WSP / VCHAR / obs-text )
    3010 <a href="#request" class="smpl">Request</a> = Request-Line *( ( general-header / request-header /
    3011  entity-header ) CRLF ) CRLF [ message-body ]
     3012<a href="#request" class="smpl">Request</a> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    30123013<a href="#request-line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF
    3013 <a href="#response" class="smpl">Response</a> = Status-Line *( ( general-header / response-header /
    3014  entity-header ) CRLF ) CRLF [ message-body ]
     3014<a href="#response" class="smpl">Response</a> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
    30153015
    30163016<a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3DIGIT
     
    30733073 / %x53.75.6E.64.61.79 ; Sunday
    30743074
    3075 <a href="#abnf.dependencies" class="smpl">entity-header</a> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    3076 
    30773075<a href="#header.fields" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text )
    30783076<a href="#header.fields" class="smpl">field-name</a> = token
     
    31533151<a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second
    31543152<a href="#rule.token.separators" class="smpl">token</a> = 1*tchar
    3155 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( entity-header CRLF )
     3153<a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF )
    31563154<a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / "compress" / "deflate" / "gzip" /
    31573155 transfer-extension
     
    34403438         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length headers"
    34413439         </li>
     3440         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
     3441         </li>
    34423442         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
    34433443         </li>
     
    34593459            <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind">
    34603460                  <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">13.1</a>, <a class="iref" href="#BCP97"><b>13.2</b></a></li>
     3461                  <li class="indline1">browser&nbsp;&nbsp;<a class="iref" href="#rfc.iref.b.1"><b>2.1</b></a></li>
    34613462               </ul>
    34623463            </li>
    34633464            <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind">
    3464                   <li class="indline1">cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.3">2.3</a></li>
    3465                   <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4">2.3</a></li>
     3465                  <li class="indline1">cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.3"><b>2.3</b></a></li>
     3466                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4"><b>2.3</b></a></li>
    34663467                  <li class="indline1">chunked (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.5">6.2.1</a></li>
    3467                   <li class="indline1">client&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">2.1</a></li>
     3468                  <li class="indline1">client&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1"><b>2.1</b></a></li>
    34683469                  <li class="indline1">Coding Format&nbsp;&nbsp;
    34693470                     <ul class="ind">
     
    34753476                  </li>
    34763477                  <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li>
    3477                   <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.1</a></li>
     3478                  <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2"><b>2.1</b></a></li>
    34783479                  <li class="indline1">Connection header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.4</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.3</a></li>
    34793480                  <li class="indline1">Content-Length header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.3</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a></li>
     
    34833484                  <li class="indline1">Date header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.4</a>, <a class="iref" href="#rfc.iref.d.3"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
    34843485                  <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li>
    3485                   <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
     3486                  <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1"><b>2.2</b></a></li>
    34863487               </ul>
    34873488            </li>
    34883489            <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">
    3489                   <li class="indline1">Effective Request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>
     3490                  <li class="indline1">effective request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>
    34903491               </ul>
    34913492            </li>
    34923493            <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind">
    3493                   <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24">2.2</a></li>
     3494                  <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>2.2</b></a></li>
    34943495                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    34953496                     <ul class="ind">
     
    36403641            </li>
    36413642            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    3642                   <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">2.2</a></li>
     3643                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>2.2</b></a></li>
     3644                  <li class="indline1">intermediary&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1"><b>2.2</b></a></li>
    36433645                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a class="iref" href="#ISO-8859-1"><b>13.1</b></a></li>
    36443646               </ul>
     
    36553657                     </ul>
    36563658                  </li>
    3657                   <li class="indline1">message&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1">2.1</a></li>
     3659                  <li class="indline1">message&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1"><b>2.1</b></a></li>
    36583660                  <li class="indline1">message/http Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>10.3.1</b></a></li>
    36593661               </ul>
     
    36643666            </li>
    36653667            <li class="indline0"><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul class="ind">
    3666                   <li class="indline1">origin server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1">2.1</a></li>
    3667                   <li class="indline1">outbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.2">2.2</a></li>
     3668                  <li class="indline1">origin server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>2.1</b></a></li>
     3669                  <li class="indline1">outbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.2"><b>2.2</b></a></li>
    36683670               </ul>
    36693671            </li>
    36703672            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    36713673                  <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>13.2</b></a></li>
    3672                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4</a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind">
    3673                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4</a></li>
    3674                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li>
    3675                         <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a></li>
    3676                         <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.1.2</a></li>
    3677                         <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.7">5.1.1</a></li>
    3678                         <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.10">7.2.3</a></li>
    3679                         <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    3680                         <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">4.1.2</a></li>
    3681                         <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a></li>
     3674                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.8">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind">
     3675                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a></li>
     3676                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a></li>
     3677                        <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a></li>
     3678                        <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.1.2</a></li>
     3679                        <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">5.1.1</a></li>
     3680                        <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">7.2.3</a></li>
     3681                        <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
     3682                        <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.1.2</a></li>
     3683                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a></li>
    36823684                     </ul>
    36833685                  </li>
    3684                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">6.4</a>, <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a><ul class="ind">
    3685                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a></li>
    3686                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li>
    3687                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">6.4</a></li>
     3686                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a>, <a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">6.4</a>, <a class="iref" href="#rfc.xref.Part3.6">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.8">A</a><ul class="ind">
     3687                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a></li>
     3688                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">6.4</a></li>
    36883689                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    3689                         <li class="indline1"><em>Appendix A.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a></li>
     3690                        <li class="indline1"><em>Appendix A.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a></li>
    36903691                     </ul>
    36913692                  </li>
     
    36983699                     </ul>
    36993700                  </li>
    3700                   <li class="indline1">proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">2.2</a></li>
     3701                  <li class="indline1">proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>2.2</b></a></li>
    37013702               </ul>
    37023703            </li>
    37033704            <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
    3704                   <li class="indline1">request&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">2.1</a></li>
     3705                  <li class="indline1">request&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1"><b>2.1</b></a></li>
    37053706                  <li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.4"><b>2.6</b></a></li>
    3706                   <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">2.1</a></li>
    3707                   <li class="indline1">reverse proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">2.2</a></li>
     3707                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2"><b>2.1</b></a></li>
     3708                  <li class="indline1">reverse proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3"><b>2.2</b></a></li>
    37083709                  <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">6.1</a>, <a class="iref" href="#RFC1123"><b>13.2</b></a></li>
    37093710                  <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">9.3</a>, <a class="iref" href="#RFC1305"><b>13.2</b></a></li>
     
    37673768            </li>
    37683769            <li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind">
    3769                   <li class="indline1">server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.1">2.1</a></li>
     3770                  <li class="indline1">server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.1"><b>2.1</b></a></li>
    37703771                  <li class="indline1"><em>Spe</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Spe.1">7.1.1</a>, <a class="iref" href="#Spe"><b>13.2</b></a></li>
     3772                  <li class="indline1">spider&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.2"><b>2.1</b></a></li>
    37713773               </ul>
    37723774            </li>
    37733775            <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind">
    3774                   <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.2"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li>
     3776                  <li class="indline1">target resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.2"><b>4.3</b></a></li>
     3777                  <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li>
    37753778                  <li class="indline1"><em>Tou1998</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>13.2</b></a></li>
    3776                   <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
    3777                   <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
    3778                   <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.1">2.2</a></li>
     3779                  <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
     3780                  <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.5"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
     3781                  <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.1"><b>2.2</b></a></li>
    37793782               </ul>
    37803783            </li>
    37813784            <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind">
    37823785                  <li class="indline1">Upgrade header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.4</a>, <a class="iref" href="#rfc.iref.u.5"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
    3783                   <li class="indline1">upstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2">2.2</a></li>
     3786                  <li class="indline1">upstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2"><b>2.2</b></a></li>
    37843787                  <li class="indline1">URI scheme&nbsp;&nbsp;
    37853788                     <ul class="ind">
     
    37893792                  </li>
    37903793                  <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#rfc.xref.USASCII.2">3.2</a>, <a class="iref" href="#USASCII"><b>13.1</b></a></li>
    3791                   <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1">2.1</a></li>
     3794                  <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1"><b>2.1</b></a></li>
    37923795               </ul>
    37933796            </li>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r964 r966  
    684684         to each request, in the order received on that connection, with one or more HTTP response messages. This document defines
    685685         the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various
    686          response messages that might be expected as a result of applying that method for the requested resource.
     686         response messages that might be expected as a result of applying that method to the target resource.
    687687      </p>
    688688      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
     
    726726  <a href="#abnf.dependencies" class="smpl">TE</a>            = &lt;TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>&gt;
    727727  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    728 </pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>&gt;
     728</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
    729729  <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> =
    730              &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>&gt;
     730             &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>&gt;
    731731  <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> =
    732              &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>&gt;
     732             &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>&gt;
    733733  <a href="#abnf.dependencies" class="smpl">Accept-Language</a> =
    734              &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>&gt;
     734             &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>&gt;
    735735</pre><div id="rfc.figure.u.4"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">ETag</a>          = &lt;ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a>&gt;
    736736  <a href="#abnf.dependencies" class="smpl">If-Match</a>      = &lt;If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>&gt;
     
    753753             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
    754754</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    755       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     755      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    756756      </p>
    757757      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
     
    765765                 / <a href="#method" class="smpl">extension-method</a>
    766766  <a href="#method" class="smpl">extension-method</a> = <a href="#core.rules" class="smpl">token</a>
    767 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the
    768          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested
     767</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
     768         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the
    769769         resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
    770770         and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;7</a>.
     
    790790         method invocation.
    791791      </p>
    792       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>
    793                  / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>
    794                  / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>
    795                  / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
     792      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>
     793                 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>
     794                 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>
     795                 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>
    796796                 / <a href="#abnf.dependencies" class="smpl">Authorization</a>            ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>
    797797                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a>
     
    811811</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    812812         or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
    813          Unrecognized header fields are treated as entity-header fields.
    814813      </p>
    815814      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
     
    883882      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
    884883         Status-Line. These header fields give information about the server and about further access to the resource identified by
    885          the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     884         the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    886885      </p>
    887886      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
     
    897896</pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    898897         or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
    899          fields. Unrecognized header fields are treated as entity-header fields.
     898         fields.
    900899      </p>
    901900      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
     
    908907      </p>
    909908      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
    910       <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p>
     909      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    911910      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    912       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     911      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    913912         rules are used (with the first applicable one being selected):
    914913      </p>
    915914      <ol>
    916          <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource
    917             at the Effective Request URI.
    918          </li>
    919          <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
    920             of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    921          </li>
    922          <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation
    923             of the resource at the Effective Request URI.
    924          </li>
    925          <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
    926             that it is a representation of the resource at the Content-Location URI (but it might not be).
     915         <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the
     916            resource identified by the effective request URI.
     917         </li>
     918         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
     919            representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     920         </li>
     921         <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
     922            is a representation of the resource identified by the effective request URI.
     923         </li>
     924         <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
     925            asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
     926            cannot be trusted unless it can be verified by other means (not defined by HTTP).
    927927         </li>
    928928         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
     
    960960      <div id="rfc.iref.m.1"></div>
    961961      <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
    962          chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements
     962         chain identified by the effective request URI. This method allows the client to determine the options and/or requirements
    963963         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    964964      </p>
     
    986986      <div id="rfc.iref.m.2"></div>
    987987      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
    988          identified by the Effective Request URI.
    989       </p>
    990       <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
     988         identified by the effective request URI.
     989      </p>
     990      <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
    991991         in the response and not the source text of the process, unless that text happens to be the output of the process.
    992992      </p>
     
    10201020      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    10211021      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
    1022          processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the
     1022         processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the
    10231023         following functions:
    10241024      </p>
     
    10291029         <li>Extending a database through an append operation.</li>
    10301030      </ul>
    1031       <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request
     1031      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
    10321032         URI.
    10331033      </p>
     
    10391039         a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    10401040      </p>
    1041       <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1041      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10421042      </p>
    10431043      <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
     
    10471047      <div id="rfc.iref.m.5"></div>
    10481048      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1049       <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request
    1050          URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not
     1049      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the effective request URI. If the effective request
     1050         URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the effective request URI does not
    10511051         point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the
    10521052         origin server can create the resource with that URI.
    10531053      </p>
    1054       <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
     1054      <p id="rfc.section.7.6.p.2">If a new resource is created at the effective request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
    10551055         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10561056      </p>
    1057       <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    1058       </p>
    1059       <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
    1060       </p>
    1061       <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
     1057      <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1058      </p>
     1059      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
     1060      </p>
     1061      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the effective request
    10621062         URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be
    10631063         a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in
     
    10711071      </p>
    10721072      <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
    1073       <p id="rfc.section.7.6.p.8">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
     1073      <p id="rfc.section.7.6.p.8">Header fields in a PUT request that are recognized as representation metadata <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored.
    10741074      </p>
    10751075      <div id="rfc.iref.d.1"></div>
    10761076      <div id="rfc.iref.m.6"></div>
    10771077      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
    1078       <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
     1078      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
    10791079         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    10801080         successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
     
    10841084         enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
    10851085      </p>
    1086       <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached representations,
     1086      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the effective request URI identifies one or more currently cached representations,
    10871087         those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method are not cacheable.
    10881088      </p>
     
    11431143      <div id="rfc.iref.s.4"></div>
    11441144      <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
    1145       <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for
    1146          example:
    1147       </p>
     1145      <p id="rfc.section.8.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p>
    11481146      <dl>
    11491147         <dt>GET</dt>
    1150          <dd>a representation corresponding to the requested resource is sent in the response;</dd>
     1148         <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd>
    11511149         <dt>HEAD</dt>
    1152          <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd>
     1150         <dd>the same representation as GET, except without the message-body;</dd>
    11531151         <dt>POST</dt>
    11541152         <dd>a representation describing or containing the result of the action;</dd>
     
    11851183      <div id="rfc.iref.s.7"></div>
    11861184      <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1187       <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-header is not the definitive set as available from the origin server, but is gathered
     1185      <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered
    11881186         from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might
    11891187         result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate
     
    11961194      <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
    11971195      <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body.
    1198          The resource metadata and representation metadata in the response message's header fields refer to the requested resource
    1199          and its current representation, respectively, after the requested action. For example, if a 204 status code is received in
    1200          response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for
    1201          the representation that was successfully PUT to the requested resource.
     1196         The resource metadata and representation metadata in the response message's header fields refer to the target resource and
     1197         its current representation, respectively, after the requested action. For example, if a 204 status code is received in response
     1198         to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation
     1199         that was successfully PUT.
    12021200      </p>
    12031201      <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input
     
    12331231      <div id="rfc.iref.s.11"></div>
    12341232      <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    1235       <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
    1236          negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
     1233      <p id="rfc.section.8.3.1.p.1">The target resource more than one representation, each with its own specific location, and agent-driven negotiation information
     1234         (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    12371235         location.
    12381236      </p>
    1239       <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of resource characteristics and location(s) from which the user or user agent can
     1237      <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can
    12401238         choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending
    12411239         upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
     
    12481246      <div id="rfc.iref.s.12"></div>
    12491247      <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
    1250       <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Effective
    1251          Request URI to one or more of the new references returned by the server, where possible.
     1248      <p id="rfc.section.8.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective
     1249         request URI to one or more of the new references returned by the server, where possible.
    12521250      </p>
    12531251      <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
     
    12661264      <div id="rfc.iref.s.13"></div>
    12671265      <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
    1268       <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the
    1269          client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests.
     1266      <p id="rfc.section.8.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    12701267      </p>
    12711268      <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     
    12851282      <p id="rfc.section.8.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides
    12861283         an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response,
    1287          be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested
    1288          resource.
     1284         be redirected again, or end with an error status. The Location URI is not a substitute reference for the effective request
     1285         URI.
    12891286      </p>
    12901287      <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action
     
    12931290      </p>
    12941291      <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    1295          transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such
    1296          that the follow-on representation might be useful without implying that it adequately represents the previously requested
     1292         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such
     1293         that the follow-on representation might be useful to recipients without implying that it adequately represents the target
    12971294         resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
    12981295         be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
     
    13181315      <div id="rfc.iref.s.18"></div>
    13191316      <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
    1320       <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests.
     1317      <p id="rfc.section.8.3.8.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    13211318      </p>
    13221319      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
     
    13601357      <div id="rfc.iref.s.23"></div>
    13611358      <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    1362       <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary
     1359      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
    13631360         or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
    13641361         and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
     
    13681365      <div id="rfc.iref.s.24"></div>
    13691366      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1370       <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
     1367      <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
    13711368      </p>
    13721369      <div id="rfc.iref.48"></div>
     
    14141411      <div id="rfc.iref.s.29"></div>
    14151412      <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
    1416       <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected
    1417          to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine,
     1413      <p id="rfc.section.8.4.11.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
     1414         be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine,
    14181415         whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead.
    14191416      </p>
     
    14491446      <div id="rfc.iref.s.33"></div>
    14501447      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
    1451       <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret.
     1448      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
    14521449         This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
    14531450         query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
    14541451         points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
    1455          in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.
     1452         in some servers using fixed-length buffers for reading or manipulating the effective request URI.
    14561453      </p>
    14571454      <div id="rfc.iref.57"></div>
     
    14591456      <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    14601457      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
    1461          requested resource for the requested method.
     1458         target resource for the requested method.
    14621459      </p>
    14631460      <div id="rfc.iref.58"></div>
     
    15231520      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    15241521      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
    1525       <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1526          receives the message.
    1527       </p>
    15281522      <div id="rfc.iref.a.1"></div>
    15291523      <div id="rfc.iref.h.2"></div>
    15301524      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    1531       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective
    1532          Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
     1525      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
     1526         this field is strictly to inform the recipient of valid methods associated with the resource.
    15331527      </p>
    15341528      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
     
    16151609      </div>
    16161610      <div class="note" id="rfc.section.9.4.p.9">
    1617          <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     1611         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    16181612            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    16191613         </p>
     
    16361630      <div id="rfc.iref.h.7"></div>
    16371631      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    1638       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request
     1632      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request
    16391633         URI was obtained (the "referrer", although the header field is misspelled.).
    16401634      </p>
     
    16441638         contain a Referer header field.
    16451639      </p>
    1646       <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
     1640      <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
    16471641         the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
    16481642         non-HTTP URIs (e.g., FTP).
     
    16521646</pre><p id="rfc.section.9.6.p.5">Example:</p>
    16531647      <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    1654 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective Request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
     1648</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
    16551649      </p>
    16561650      <div id="rfc.iref.r.2"></div>
     
    22592253         user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>)
    22602254      </p>
    2261       <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource
     2255      <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
    22622256         must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    22632257         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;8.3.6</a>)
     
    27592753                  </li>
    27602754                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind">
    2761                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
    2762                         <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
    2763                         <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
    2764                         <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
    2765                         <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
    2766                         <li class="indline1"><em>Section 5.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
     2755                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
     2756                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
     2757                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
     2758                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
     2759                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
     2760                        <li class="indline1"><em>Section 6.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
    27672761                     </ul>
    27682762                  </li>
  • draft-ietf-httpbis/latest/p3-payload.html

    r964 r966  
    377377      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    378378      <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2">
    379       <link rel="Chapter" title="3 Representation" href="#rfc.section.3">
    380       <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4">
    381       <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
    382       <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
    383       <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
    384       <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
    385       <link rel="Chapter" href="#rfc.section.9" title="9 References">
     379      <link rel="Chapter" title="3 Payload" href="#rfc.section.3">
     380      <link rel="Chapter" title="4 Representation" href="#rfc.section.4">
     381      <link rel="Chapter" title="5 Content Negotiation" href="#rfc.section.5">
     382      <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6">
     383      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
     384      <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8">
     385      <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9">
     386      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    386387      <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
    387388      <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
     
    555556            </ul>
    556557         </li>
    557          <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
    558                <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#entity.header.fields">Entity Header Fields</a></li>
    559                <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a><ul class="toc">
    560                      <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
    561                   </ul>
    562                </li>
     558         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#payload">Payload</a><ul class="toc">
     559               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
     560               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a></li>
    563561            </ul>
    564562         </li>
    565          <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul class="toc">
    566                <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
    567                <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
     563         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
     564               <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
     565               <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    568566            </ul>
    569567         </li>
    570          <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
    571                <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
    572                <li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
    573                <li class="tocline1">5.3&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
    574                <li class="tocline1">5.4&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
    575                <li class="tocline1">5.5&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
    576                <li class="tocline1">5.6&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
    577                <li class="tocline1">5.7&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
    578                <li class="tocline1">5.8&nbsp;&nbsp;&nbsp;<a href="#header.content-md5">Content-MD5</a></li>
    579                <li class="tocline1">5.9&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
     568         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul class="toc">
     569               <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
     570               <li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
    580571            </ul>
    581572         </li>
    582          <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
    583                <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    584                <li class="tocline1">6.2&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
     573         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
     574               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
     575               <li class="tocline1">6.2&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
     576               <li class="tocline1">6.3&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
     577               <li class="tocline1">6.4&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
     578               <li class="tocline1">6.5&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
     579               <li class="tocline1">6.6&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
     580               <li class="tocline1">6.7&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
     581               <li class="tocline1">6.8&nbsp;&nbsp;&nbsp;<a href="#header.content-md5">Content-MD5</a></li>
     582               <li class="tocline1">6.9&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
    585583            </ul>
    586584         </li>
    587          <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
    588                <li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
    589                <li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#content-disposition.issues">Content-Disposition Issues</a></li>
     585         <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
     586               <li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     587               <li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
    590588            </ul>
    591589         </li>
    592          <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
    593          <li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
    594                <li class="tocline1">9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    595                <li class="tocline1">9.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     590         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
     591               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
     592               <li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#content-disposition.issues">Content-Disposition Issues</a></li>
     593            </ul>
     594         </li>
     595         <li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
     596         <li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
     597               <li class="tocline1">10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     598               <li class="tocline1">10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    596599            </ul>
    597600         </li>
     
    648651         <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can
    649652            be negotiated (including error responses).
    650          </li>
    651       </ul>
    652       <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.p.1"></span>  <dfn>payload</dfn> 
    653       </p>
    654       <ul class="empty">
    655          <li>The information transferred within a given message is called the payload, consisting of optional payload metadata and an optional
    656             payload body. The payload in HTTP is always a partial or complete representation of some resource, though which resource is
    657             represented is dependent on the type of message (request or response), the request method, and the response status code.
    658          </li>
    659       </ul>
    660       <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.r.1"></span>  <dfn>representation</dfn> 
    661       </p>
    662       <ul class="empty">
    663          <li>A representation is information in a format that can be readily communicated from one party to another. For our purposes,
    664             a representation is binary data and its associated metadata. A representation of a resource is information that reflects the
    665             state of that resource, as observed at some point in the past or to be desired at some point in the future.
    666653         </li>
    667654      </ul>
     
    744731      </p>
    745732      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
    746 </pre><p id="rfc.section.2.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;5.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;5.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
     733</pre><p id="rfc.section.2.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    747734         mechanism will be required to remove the encoding.
    748735      </p>
     
    788775      </p>
    789776      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    790       <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
     777      <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;6.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
    791778      </p>
    792779      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
     
    860847</pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
    861848      </p>
    862       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    863       <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
    864          of entity-header fields and a representation body, although some responses will only include the entity-headers.
    865       </p>
    866       <p id="rfc.section.3.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives
    867          the message.
    868       </p>
    869       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>
    870       <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is
    871          present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the
    872          Effective Request URI.
    873       </p>
    874       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#entity.header.fields" class="smpl">entity-header</a>  = <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
    875                  / <a href="#header.content-language" class="smpl">Content-Language</a>         ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;5.6</a>
    876                  / <a href="#abnf.dependencies" class="smpl">Content-Length</a>           ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a>
    877                  / <a href="#header.content-location" class="smpl">Content-Location</a>         ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;5.7</a>
    878                  / <a href="#header.content-md5" class="smpl">Content-MD5</a>              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;5.8</a>
    879                  / <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
    880                  / <a href="#header.content-type" class="smpl">Content-Type</a>             ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;5.9</a>
    881                  / <a href="#abnf.dependencies" class="smpl">Expires</a>                  ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>
    882                  / <a href="#abnf.dependencies" class="smpl">Last-Modified</a>            ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>
    883                  / <a href="#entity.header.fields" class="smpl">extension-header</a>
    884  
    885   <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">header-field</a>
    886 </pre><p id="rfc.section.3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these
    887          fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies.
    888       </p>
    889       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    890       <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
    891       <p id="rfc.section.3.2.p.2">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     849      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
     850      <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
     851         in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
     852         has been decoded.
     853      </p>
     854      <div id="rfc.iref.p.1"></div>
     855      <p id="rfc.section.3.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation
     856         because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s)
     857         of the representation (e.g., the 206 status code).
     858      </p>
     859      <p id="rfc.section.3.p.3">define metadata for the whole representation, which we refer to as "representation header fields", while others define only
     860         metadata about what is included in the message, which we
     861      </p>
     862      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h2>
     863      <p id="rfc.section.3.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload
     864         header fields". The following payload header fields are defined by HTTP/1.1:
     865      </p>
     866      <div id="rfc.figure.u.12"></div><pre>   <a href="#abnf.dependencies" class="smpl">Content-Length</a>           ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a>
     867   <a href="#header.content-md5" class="smpl">Content-MD5</a>              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;6.8</a>
     868   <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
     869</pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
     870      <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    892871         safe and proper transfer of the message.
    893872      </p>
    894       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="type" href="#type">Type</a></h3>
    895       <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type
    896          and Content-Encoding. These define a two-layer, ordered encoding model:
    897       </p>
    898       <div id="rfc.figure.u.13"></div><pre class="text">  payload-body := Content-Encoding( Content-Type( data ) )
    899 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a payload body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.
    900       </p>
    901       <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
    902       </p>
    903       <p id="rfc.section.3.2.1.p.5">In practice, currently-deployed servers sometimes provide a Content-Type header which does not correctly convey the intended
    904          interpretation of the content sent, with the result that some clients will examine the response body's content and override
    905          the specified type.
    906       </p>
    907       <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
    908          Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
    909       </p>
    910       <p id="rfc.section.3.2.1.p.7">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
    911          that are a property of the representation. There is no default encoding.
    912       </p>
    913       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    914       <p id="rfc.section.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
     873      <div id="rfc.iref.r.1"></div>
     874      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
     875      <p id="rfc.section.4.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
     876         that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
     877         at some point in the future (e.g., in a PUT request).
     878      </p>
     879      <p id="rfc.section.4.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
     880         identified by the effective request URI). The precise semantics of a representation are determined by the type of message
     881         (request or response), the request method, the response status code, and the representation metadata. For example, the above
     882         semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
     883         response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
     884         the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
     885         URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
     886         next steps are suggested for resolving it.
     887      </p>
     888      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
     889      <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
     890         is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
     891         the same effective request URI.
     892      </p>
     893      <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
     894      <div id="rfc.figure.u.13"></div><pre>   <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;6.5</a>
     895   <a href="#header.content-language" class="smpl">Content-Language</a>         ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;6.6</a>
     896   <a href="#header.content-location" class="smpl">Content-Location</a>         ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;6.7</a>
     897   <a href="#header.content-type" class="smpl">Content-Type</a>             ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;6.9</a>
     898   <a href="#abnf.dependencies" class="smpl">Expires</a>                  ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>
     899   <a href="#abnf.dependencies" class="smpl">Last-Modified</a>            ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>
     900</pre><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
     901      <p id="rfc.section.4.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     902         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
     903         the representation metadata header fields.
     904      </p>
     905      <p id="rfc.section.4.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
     906         a two-layer, ordered encoding model:
     907      </p>
     908      <div id="rfc.figure.u.14"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
     909</pre><p id="rfc.section.4.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
     910         body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
     911         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
     912         of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
     913      </p>
     914      <p id="rfc.section.4.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     915         a given representation, with the result that some clients will examine a response body's content and override the specified
     916         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
     917         escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
     918         match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
     919         such "content sniffing" when it is used.
     920      </p>
     921      <p id="rfc.section.4.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
     922         that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
     923         that defined by the Content-Type.
     924      </p>
     925      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
     926      <p id="rfc.section.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
    915927         processing. Often, the server has different ways of representing the same information; for example, in different formats,
    916928         languages, or using different character encodings.
    917929      </p>
    918       <p id="rfc.section.4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
     930      <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
    919931         which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
    920932         provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource,
    921933         when more than one is available.
    922934      </p>
    923       <p id="rfc.section.4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
     935      <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
    924936         based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
    925937         for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
     
    927939         parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    928940      </p>
    929       <p id="rfc.section.4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
     941      <p id="rfc.section.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    930942         of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    931943         a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    932944         to choose from is very large, agent-driven negotiation might not be appropriate.
    933945      </p>
    934       <p id="rfc.section.4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
     946      <p id="rfc.section.5.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
    935947         be considered to be the "same information".
    936948      </p>
    937       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
    938       <p id="rfc.section.4.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven
     949      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
     950      <p id="rfc.section.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven
    939951         negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    940952         language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    941953         pertaining to the request (such as the network address of the client).
    942954      </p>
    943       <p id="rfc.section.4.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
     955      <p id="rfc.section.5.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
    944956         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    945957         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    946958         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
    947959      </p>
    948       <p id="rfc.section.4.1.p.3">Server-driven negotiation has disadvantages: </p>
     960      <p id="rfc.section.5.1.p.3">Server-driven negotiation has disadvantages: </p>
    949961      <ol>
    950962         <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
     
    958970         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    959971      </ol>
    960       <p id="rfc.section.4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
    961          capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension
     972      <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
     973         capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension
    962974         header fields not defined by this specification.
    963975      </p>
    964       <div class="note" id="rfc.section.4.1.p.5">
     976      <div class="note" id="rfc.section.5.1.p.5">
    965977         <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
    966978         </p>
    967979      </div>
    968       <p id="rfc.section.4.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
    969       </p>
    970       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
    971       <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
     980      <p id="rfc.section.5.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
     981      </p>
     982      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
     983      <p id="rfc.section.5.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
    972984         an initial response from the origin server. Selection is based on a list of the available representations of the response
    973985         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     
    975987         user selecting from a generated (possibly hypertext) menu.
    976988      </p>
    977       <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
     989      <p id="rfc.section.5.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
    978990         or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    979991         when public caches are used to distribute server load and reduce network usage.
    980992      </p>
    981       <p id="rfc.section.4.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
     993      <p id="rfc.section.5.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
    982994         This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    983995         for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    984996         and used within HTTP/1.1.
    985997      </p>
    986       <p id="rfc.section.4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
     998      <p id="rfc.section.5.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
    987999         when the server is unwilling or unable to provide a varying response using server-driven negotiation.
    9881000      </p>
    989       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    990       <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>
    991       <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    992          receives the message.
    993       </p>
     1001      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     1002      <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>
    9941003      <div id="rfc.iref.a.1"></div>
    9951004      <div id="rfc.iref.h.1"></div>
    996       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    997       <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
     1005      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
     1006      <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
    9981007         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
    9991008         for an in-line image.
    10001009      </p>
    1001       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
     1010      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
    10021011  <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
    10031012 
     
    10091018  <a href="#header.accept" class="smpl">accept-ext</a>     = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a>
    10101019                   [ "=" <a href="#core.rules" class="smpl">word</a> ]
    1011 </pre><p id="rfc.section.5.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating
     1020</pre><p id="rfc.section.6.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating
    10121021         all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range.
    10131022      </p>
    1014       <p id="rfc.section.5.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
     1023      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    10151024         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    10161025         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    10171026      </p>
    1018       <div class="note" id="rfc.section.5.1.p.5">
     1027      <div class="note" id="rfc.section.6.1.p.5">
    10191028         <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
    10201029            Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
     
    10231032         </p>
    10241033      </div>
    1025       <p id="rfc.section.5.1.p.6">The example</p>
    1026       <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    1027 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
     1034      <p id="rfc.section.6.1.p.6">The example</p>
     1035      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
     1036</pre><p id="rfc.section.6.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    10281037         quality".
    10291038      </p>
    1030       <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
     1039      <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    10311040         is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
    10321041         the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
    10331042      </p>
    1034       <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
    1035       <div id="rfc.figure.u.16"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
     1043      <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
     1044      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10361045          text/x-dvi; q=0.8, text/x-c
    1037 </pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
     1046</pre><p id="rfc.section.6.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    10381047         send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
    10391048      </p>
    1040       <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
     1049      <p id="rfc.section.6.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    10411050         to a given type, the most specific reference has precedence. For example,
    10421051      </p>
    1043       <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
    1044 </pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
     1052      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
     1053</pre><p id="rfc.section.6.1.p.15">have the following precedence: </p>
    10451054      <ol>
    10461055         <li>text/html;level=1</li>
     
    10491058         <li>*/*</li>
    10501059      </ol>
    1051       <p id="rfc.section.5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
     1060      <p id="rfc.section.6.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
    10521061         which matches that type. For example,
    10531062      </p>
    1054       <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     1063      <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10551064          text/html;level=2;q=0.4, */*;q=0.5
    1056 </pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
     1065</pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p>
    10571066      <div id="rfc.table.u.1">
    10581067         <table class="tt full left" cellpadding="3" cellspacing="0">
     
    10911100         </table>
    10921101      </div>
    1093       <p id="rfc.section.5.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
     1102      <p id="rfc.section.6.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
    10941103         is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
    10951104      </p>
    10961105      <div id="rfc.iref.a.2"></div>
    10971106      <div id="rfc.iref.h.2"></div>
    1098       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
    1099       <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
     1107      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
     1108      <p id="rfc.section.6.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
    11001109         This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
    11011110         to a server which is capable of representing documents in those character sets.
    11021111      </p>
    1103       <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
     1112      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
    11041113          <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a>
    11051114  <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
    11061115                         [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    1107 </pre><p id="rfc.section.5.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
     1116</pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
    11081117         example is
    11091118      </p>
    1110       <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    1111 </pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
     1119      <div id="rfc.figure.u.21"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     1120</pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
    11121121         not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
    11131122         not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly
    11141123         mentioned.
    11151124      </p>
    1116       <p id="rfc.section.5.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
     1125      <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
    11171126         present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
    11181127      </p>
    11191128      <div id="rfc.iref.a.3"></div>
    11201129      <div id="rfc.iref.h.3"></div>
    1121       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1122       <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
    1123       </p>
    1124       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
     1130      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
     1131      <p id="rfc.section.6.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
     1132      </p>
     1133      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
    11251134                     <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>
    11261135  <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>  =
    11271136                     #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    11281137  <a href="#header.accept-encoding" class="smpl">codings</a>            = ( <a href="#content.codings" class="smpl">content-coding</a> / "*" )
    1129 </pre><p id="rfc.section.5.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
    1130       </p>
    1131       <p id="rfc.section.5.3.p.4">Examples of its use are:</p>
    1132       <div id="rfc.figure.u.22"></div><pre class="text">  Accept-Encoding: compress, gzip
     1138</pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
     1139      </p>
     1140      <p id="rfc.section.6.3.p.4">Examples of its use are:</p>
     1141      <div id="rfc.figure.u.23"></div><pre class="text">  Accept-Encoding: compress, gzip
    11331142  Accept-Encoding:
    11341143  Accept-Encoding: *
    11351144  Accept-Encoding: compress;q=0.5, gzip;q=1.0
    11361145  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
    1137 </pre><p id="rfc.section.5.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
     1146</pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
    11381147      <ol>
    11391148         <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
     
    11491158         </li>
    11501159      </ol>
    1151       <p id="rfc.section.5.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
     1160      <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
    11521161         to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
    11531162      </p>
    1154       <p id="rfc.section.5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
     1163      <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
    11551164         then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the
    11561165         client.
    11571166      </p>
    1158       <div class="note" id="rfc.section.5.3.p.9">
     1167      <div class="note" id="rfc.section.6.3.p.9">
    11591168         <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    11601169            commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
     
    11631172         </p>
    11641173      </div>
    1165       <div class="note" id="rfc.section.5.3.p.10">
     1174      <div class="note" id="rfc.section.6.3.p.10">
    11661175         <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    11671176            not work and are not permitted with x-gzip or x-compress.
     
    11701179      <div id="rfc.iref.a.4"></div>
    11711180      <div id="rfc.iref.h.4"></div>
    1172       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
    1173       <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred
     1181      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
     1182      <p id="rfc.section.6.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred
    11741183         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    11751184      </p>
    1176       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
     1185      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
    11771186                    <a href="#header.accept-language" class="smpl">Accept-Language-v</a>
    11781187  <a href="#header.accept-language" class="smpl">Accept-Language-v</a> =
     
    11801189  <a href="#header.accept-language" class="smpl">language-range</a>    =
    11811190            &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
    1182 </pre><p id="rfc.section.5.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
     1191</pre><p id="rfc.section.6.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
    11831192         languages specified by that range. The quality value defaults to "q=1". For example,
    11841193      </p>
    1185       <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    1186 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    1187       </p>
    1188       <p id="rfc.section.5.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
    1189       </p>
    1190       <div class="note" id="rfc.section.5.4.p.7">
     1194      <div id="rfc.figure.u.25"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     1195</pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
     1196      </p>
     1197      <p id="rfc.section.6.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
     1198      </p>
     1199      <div class="note" id="rfc.section.6.4.p.7">
    11911200         <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    11921201         </p>
    11931202      </div>
    1194       <p id="rfc.section.5.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
    1195          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;7.1</a>.
    1196       </p>
    1197       <p id="rfc.section.5.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
     1203      <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
     1204         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;8.1</a>.
     1205      </p>
     1206      <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    11981207         of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request.
    11991208      </p>
    1200       <div class="note" id="rfc.section.5.4.p.10">
     1209      <div class="note" id="rfc.section.6.4.p.10">
    12011210         <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    12021211            familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
     
    12071216      <div id="rfc.iref.c.7"></div>
    12081217      <div id="rfc.iref.h.5"></div>
    1209       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1210       <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the representation, and thus
    1211          what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
     1218      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
     1219      <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what
     1220         decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
    12121221         is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
    12131222      </p>
    1214       <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
     1223      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
    12151224  <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    1216 </pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
    1217       </p>
    1218       <div id="rfc.figure.u.26"></div><pre class="text">  Content-Encoding: gzip
    1219 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     1225</pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
     1226      </p>
     1227      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
     1228</pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
    12201229         and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    12211230         directive is present in the message.
    12221231      </p>
    1223       <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;5.5</a>) that lists the non-identity content-coding(s) used.
    1224       </p>
    1225       <p id="rfc.section.5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
    1226       </p>
    1227       <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1232      <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the non-identity content-coding(s) used.
     1233      </p>
     1234      <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1235      </p>
     1236      <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    12281237      </p>
    12291238      <div id="rfc.iref.c.8"></div>
    12301239      <div id="rfc.iref.h.6"></div>
    1231       <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    1232       <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.
    1233          Note that this might not be equivalent to all the languages used within the representation.
    1234       </p>
    1235       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
     1240      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
     1241      <p id="rfc.section.6.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
     1242         that this might not be equivalent to all the languages used within the representation.
     1243      </p>
     1244      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
    12361245  <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    1237 </pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
     1246</pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    12381247         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    12391248         field is
    12401249      </p>
    1241       <div id="rfc.figure.u.28"></div><pre class="text">  Content-Language: da
    1242 </pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
     1250      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
     1251</pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
    12431252         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
    12441253         it is intended.
    12451254      </p>
    1246       <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
     1255      <p id="rfc.section.6.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
    12471256         simultaneously in the original Maori and English versions, would call for
    12481257      </p>
    1249       <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
    1250 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
     1258      <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
     1259</pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    12511260         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    12521261         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    12531262      </p>
    1254       <p id="rfc.section.5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
     1263      <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
    12551264      </p>
    12561265      <div id="rfc.iref.c.9"></div>
    12571266      <div id="rfc.iref.h.7"></div>
    1258       <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    1259       <p id="rfc.section.5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
     1267      <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
     1268      <p id="rfc.section.6.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
    12601269         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
    12611270         would contain the same representation that is enclosed as payload in this message.
    12621271      </p>
    1263       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
     1272      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
    12641273                    <a href="#header.content-location" class="smpl">Content-Location-v</a>
    12651274  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12661275                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1267 </pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1276</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    12681277         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    12691278      </p>
    1270       <p id="rfc.section.5.7.p.4">If Content-Location is included in a response message and its value is the same as the Effective Request URI, then the response
     1279      <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
    12711280         payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
    12721281         when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's
     
    12751284         need for a subsequent GET request.
    12761285      </p>
    1277       <p id="rfc.section.5.7.p.5">If Content-Location is included in a response message and its value differs from the Effective Request URI, then the origin
     1286      <p id="rfc.section.6.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
    12781287         server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
    1279          request, this is an indication that the Effective Request URI identifies a resource that is subject to content negotiation
     1288         request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
    12801289         and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
    12811290         indicates that this representation contains a report on the action's status and the same report is available (for future access
     
    12841293         in the future.
    12851294      </p>
    1286       <p id="rfc.section.5.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
     1295      <p id="rfc.section.6.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
    12871296         representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
    12881297         providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
     
    12921301         latter semantics, it would have applied the PUT directly to the Content-Location URI.
    12931302      </p>
    1294       <p id="rfc.section.5.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
     1303      <p id="rfc.section.6.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
    12951304         in other contexts, such as within source links or other metadata.
    12961305      </p>
    1297       <p id="rfc.section.5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
     1306      <p id="rfc.section.6.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
    12981307         to respond to later requests on that Content-Location URI.
    12991308      </p>
    1300       <p id="rfc.section.5.7.p.9">If the Content-Location value is a partial URI, it is interpreted relative to the Effective Request URI.</p>
     1309      <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
    13011310      <div id="rfc.iref.c.10"></div>
    13021311      <div id="rfc.iref.h.8"></div>
    1303       <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
    1304       <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
     1312      <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
     1313      <p id="rfc.section.6.8.p.1">The "Content-MD5" header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
    13051314         message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload
    13061315         body in transit, but is not proof against malicious attacks.
    13071316      </p>
    1308       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
     1317      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
    13091318  <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>&gt;
    1310 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
     1319</pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
    13111320         agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
    13121321      </p>
    1313       <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
     1322      <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
    13141323         applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response
    13151324         chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload.
    13161325      </p>
    1317       <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
     1326      <p id="rfc.section.6.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
    13181327         but this does not change how the digest is computed as defined in the preceding paragraph.
    13191328      </p>
    1320       <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
     1329      <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
    13211330         headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
    13221331         body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
    13231332         The Transfer-Encoding header field is not allowed within body-parts.
    13241333      </p>
    1325       <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
    1326       </p>
    1327       <div class="note" id="rfc.section.5.8.p.8">
     1334      <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
     1335      </p>
     1336      <div class="note" id="rfc.section.6.8.p.8">
    13281337         <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
    13291338            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
     
    13361345      <div id="rfc.iref.c.11"></div>
    13371346      <div id="rfc.iref.h.9"></div>
    1338       <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    1339       <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD
    1340          method, the media type is that which would have been sent had the request been a GET.
    1341       </p>
    1342       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
     1347      <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
     1348      <p id="rfc.section.6.9.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
     1349         the media type is that which would have been sent had the request been a GET.
     1350      </p>
     1351      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
    13431352  <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a>
    1344 </pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
    1345       </p>
    1346       <div id="rfc.figure.u.33"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    1347 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
    1348       </p>
    1349       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    1350       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1351       <p id="rfc.section.6.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1353</pre><p id="rfc.section.6.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
     1354      </p>
     1355      <div id="rfc.figure.u.34"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
     1356</pre><p id="rfc.section.6.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;4.2</a>.
     1357      </p>
     1358      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     1359      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     1360      <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    13521361      </p>
    13531362      <div id="rfc.table.1">
     
    13671376                  <td class="left">http</td>
    13681377                  <td class="left">standard</td>
    1369                   <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.1</a>
     1378                  <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.1</a>
    13701379                  </td>
    13711380               </tr>
     
    13741383                  <td class="left">http</td>
    13751384                  <td class="left">standard</td>
    1376                   <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;5.2</a>
     1385                  <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.2</a>
    13771386                  </td>
    13781387               </tr>
     
    13811390                  <td class="left">http</td>
    13821391                  <td class="left">standard</td>
    1383                   <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3</a>
     1392                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3</a>
    13841393                  </td>
    13851394               </tr>
     
    13881397                  <td class="left">http</td>
    13891398                  <td class="left">standard</td>
    1390                   <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;5.4</a>
     1399                  <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.4</a>
    13911400                  </td>
    13921401               </tr>
     
    14021411                  <td class="left">http</td>
    14031412                  <td class="left">standard</td>
    1404                   <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;5.5</a>
     1413                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;6.5</a>
    14051414                  </td>
    14061415               </tr>
     
    14091418                  <td class="left">http</td>
    14101419                  <td class="left">standard</td>
    1411                   <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;5.6</a>
     1420                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;6.6</a>
    14121421                  </td>
    14131422               </tr>
     
    14161425                  <td class="left">http</td>
    14171426                  <td class="left">standard</td>
    1418                   <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;5.7</a>
     1427                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;6.7</a>
    14191428                  </td>
    14201429               </tr>
     
    14231432                  <td class="left">http</td>
    14241433                  <td class="left">standard</td>
    1425                   <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section&nbsp;5.8</a>
     1434                  <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section&nbsp;6.8</a>
    14261435                  </td>
    14271436               </tr>
     
    14301439                  <td class="left">http</td>
    14311440                  <td class="left">standard</td>
    1432                   <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;5.9</a>
     1441                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;6.9</a>
    14331442                  </td>
    14341443               </tr>
     
    14431452         </table>
    14441453      </div>
    1445       <p id="rfc.section.6.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1446       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>
    1447       <p id="rfc.section.6.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
    1448       </p>
    1449       <p id="rfc.section.6.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registration below:
     1454      <p id="rfc.section.7.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1455      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>
     1456      <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
     1457      </p>
     1458      <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registration below:
    14501459      </p>
    14511460      <div id="rfc.table.2">
     
    14881497         </table>
    14891498      </div>
    1490       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1491       <p id="rfc.section.7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
     1499      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     1500      <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    14921501         as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    14931502         make some suggestions for reducing security risks.
    14941503      </p>
    1495       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
    1496       <p id="rfc.section.7.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
     1504      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
     1505      <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
    14971506         in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
    14981507         languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
     
    15001509         process include a message which makes the user aware of the loss of privacy involved.
    15011510      </p>
    1502       <p id="rfc.section.7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
     1511      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
    15031512         and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any
    15041513         Vary response-header fields generated by the server, that such sending could improve the quality of service.
    15051514      </p>
    1506       <p id="rfc.section.7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
     1515      <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
    15071516         used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
    15081517         to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
     
    15121521         filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
    15131522      </p>
    1514       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>
    1515       <p id="rfc.section.7.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix&nbsp;B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the
     1523      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>
     1524      <p id="rfc.section.8.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix&nbsp;B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the
    15161525         HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See <a href="http://tools.ietf.org/html/rfc2183#section-5">Section 5</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> for details.
    15171526      </p>
    1518       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    1519       <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
     1527      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
     1528      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    15201529      </h1>
    1521       <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References
     1530      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    15221531      </h2>
    15231532      <table>                               
     
    16051614         </tr>
    16061615      </table>
    1607       <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
     1616      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    16081617      </h2>
    16091618      <table>                               
     
    17241733         environments.
    17251734      </p>
    1726       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
     1735      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
    17271736  <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
    17281737</pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this
     
    17821791         in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
    17831792      </p>
    1784       <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
     1793      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
    17851794                        <a href="#content-disposition" class="smpl">content-disposition-v</a>
    17861795  <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a>
     
    17921801  <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a>
    17931802</pre><p id="rfc.section.B.1.p.3">An example is</p>
    1794       <div id="rfc.figure.u.36"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
     1803      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
    17951804</pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply
    17961805         to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only.
     
    17991808         agent should not display the response, but directly enter a "save response as..." dialog.
    18001809      </p>
    1801       <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section&nbsp;7.2</a> for Content-Disposition security issues.
     1810      <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section&nbsp;8.2</a> for Content-Disposition security issues.
    18021811      </p>
    18031812      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
     
    18061815      <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    18071816         servers emitting bogus Content-Location headers, and also the potentially undesirable effect of potentially breaking relative
    1808          links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;5.7</a>)
     1817         links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
    18091818      </p>
    18101819      <p id="rfc.section.C.p.3">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    18111820      </p>
    18121821      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    1813       <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
     1822      <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
    18141823<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v
    18151824<a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
     
    18681877<a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token
    18691878
    1870 <a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length
    1871  / Content-Location / Content-MD5 / Content-Range / Content-Type /
    1872  Expires / Last-Modified / extension-header
    1873 <a href="#entity.header.fields" class="smpl">extension-header</a> = header-field
    1874 
    18751879<a href="#content-disposition" class="smpl">filename-parm</a> = "filename=" quoted-string
    18761880
     
    18981902
    18991903<a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
    1900 </pre> <div id="rfc.figure.u.38"></div>
     1904</pre> <div id="rfc.figure.u.39"></div>
    19011905      <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
    19021906; Accept-Charset defined but not used
     
    19051909; MIME-Version defined but not used
    19061910; content-disposition defined but not used
    1907 ; entity-header defined but not used
    19081911</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    19091912      <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC2616
     
    20902093         <ul class="ind">
    20912094            <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind">
    2092                   <li class="indline1">Accept header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>
    2093                   <li class="indline1">Accept-Charset header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>
    2094                   <li class="indline1">Accept-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>
    2095                   <li class="indline1">Accept-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>
     2095                  <li class="indline1">Accept header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li>
     2096                  <li class="indline1">Accept-Charset header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li>
     2097                  <li class="indline1">Accept-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li>
     2098                  <li class="indline1">Accept-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li>
    20962099               </ul>
    20972100            </li>
    20982101            <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind">
    2099                   <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">9.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">9.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">9.1</a>, <a class="iref" href="#BCP97"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li>
     2102                  <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">10.1</a>, <a class="iref" href="#BCP97"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li>
    21002103               </ul>
    21012104            </li>
     
    21112114                  <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.2</a></li>
    21122115                  <li class="indline1">content negotiation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">1.1</a></li>
    2113                   <li class="indline1">Content-Disposition header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
    2114                   <li class="indline1">Content-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>
    2115                   <li class="indline1">Content-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>
    2116                   <li class="indline1">Content-Location header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
    2117                   <li class="indline1">Content-MD5 header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b>5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>
    2118                   <li class="indline1">Content-Type header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>
     2116                  <li class="indline1">Content-Disposition header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
     2117                  <li class="indline1">Content-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li>
     2118                  <li class="indline1">Content-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li>
     2119                  <li class="indline1">Content-Location header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
     2120                  <li class="indline1">Content-MD5 header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li>
     2121                  <li class="indline1">Content-Type header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li>
    21192122               </ul>
    21202123            </li>
     
    21262129                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    21272130                     <ul class="ind">
    2128                         <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li>
    2129                         <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li>
    2130                         <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
    2131                         <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li>
    2132                         <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
    2133                         <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
    2134                         <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li>
    2135                         <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
    2136                         <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
    2137                         <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
     2131                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>6.1</b></a></li>
     2132                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>6.2</b></a></li>
     2133                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>6.2</b></a></li>
     2134                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>6.3</b></a></li>
     2135                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>6.3</b></a></li>
     2136                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>6.1</b></a></li>
     2137                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>6.4</b></a></li>
     2138                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>6.4</b></a></li>
     2139                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>6.1</b></a></li>
     2140                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>6.1</b></a></li>
    21382141                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
    21392142                        <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
    2140                         <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
     2143                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>6.3</b></a></li>
    21412144                        <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
    2142                         <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
    2143                         <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
    2144                         <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
    2145                         <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
    2146                         <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li>
    2147                         <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
    2148                         <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li>
    2149                         <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
    2150                         <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li>
    2151                         <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
    2152                         <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li>
    2153                         <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
    2154                         <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
    2155                         <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
    2156                         <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
    2157                         <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
    2158                         <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li>
    2159                         <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li>
    2160                         <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
    2161                         <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
     2145                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li>
     2146                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li>
     2147                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>6.5</b></a></li>
     2148                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>6.5</b></a></li>
     2149                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>6.6</b></a></li>
     2150                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>6.6</b></a></li>
     2151                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>6.7</b></a></li>
     2152                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>6.7</b></a></li>
     2153                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>6.8</b></a></li>
     2154                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>6.8</b></a></li>
     2155                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>6.9</b></a></li>
     2156                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>6.9</b></a></li>
     2157                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
     2158                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
     2159                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
     2160                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
     2161                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
     2162                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>6.4</b></a></li>
    21622163                        <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
    2163                         <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
     2164                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>6.1</b></a></li>
    21642165                        <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
    2165                         <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li>
    2166                         <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
     2166                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>A.1</b></a></li>
     2167                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>A.1</b></a></li>
    21672168                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
    21682169                        <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
     
    21772178                  <li class="indline1">Headers&nbsp;&nbsp;
    21782179                     <ul class="ind">
    2179                         <li class="indline1">Accept&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>
    2180                         <li class="indline1">Accept-Charset&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>
    2181                         <li class="indline1">Accept-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>
    2182                         <li class="indline1">Accept-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>
    2183                         <li class="indline1">Content-Disposition&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
    2184                         <li class="indline1">Content-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>
    2185                         <li class="indline1">Content-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>
    2186                         <li class="indline1">Content-Location&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
    2187                         <li class="indline1">Content-MD5&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>
    2188                         <li class="indline1">Content-Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>
    2189                         <li class="indline1">MIME-Version&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">6.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li>
     2180                        <li class="indline1">Accept&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li>
     2181                        <li class="indline1">Accept-Charset&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li>
     2182                        <li class="indline1">Accept-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li>
     2183                        <li class="indline1">Accept-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li>
     2184                        <li class="indline1">Content-Disposition&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
     2185                        <li class="indline1">Content-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li>
     2186                        <li class="indline1">Content-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li>
     2187                        <li class="indline1">Content-Location&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
     2188                        <li class="indline1">Content-MD5&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li>
     2189                        <li class="indline1">Content-Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li>
     2190                        <li class="indline1">MIME-Version&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li>
    21902191                     </ul>
    21912192                  </li>
     
    21942195            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    21952196                  <li class="indline1">identity (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">2.2</a></li>
    2196                   <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>9.1</b></a></li>
     2197                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>10.1</b></a></li>
    21972198               </ul>
    21982199            </li>
    21992200            <li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind">
    2200                   <li class="indline1">MIME-Version header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">6.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li>
     2201                  <li class="indline1">MIME-Version header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li>
    22012202               </ul>
    22022203            </li>
    22032204            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2204                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.7</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">
     2205                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a>, <a class="iref" href="#rfc.xref.Part1.21">6.7</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a>, <a class="iref" href="#Part1"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">
    22052206                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li>
    22062207                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li>
     
    22082209                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li>
    22092210                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li>
    2210                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">5.7</a></li>
     2211                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6.7</a></li>
    22112212                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">A.3</a></li>
    22122213                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li>
    2213                         <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a></li>
     2214                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a></li>
    22142215                        <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li>
    2215                         <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li>
    2216                         <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
    2217                         <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a></li>
     2216                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a></li>
     2217                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a></li>
     2218                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a></li>
    22182219                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li>
    22192220                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.6</a></li>
    22202221                     </ul>
    22212222                  </li>
    2222                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
    2223                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a></li>
     2223                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">5.1</a>, <a class="iref" href="#Part2"><b>10.1</b></a><ul class="ind">
     2224                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">5.1</a></li>
    22242225                     </ul>
    22252226                  </li>
    2226                   <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">3.1</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">
    2227                         <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">3.1</a></li>
     2227                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a>, <a class="iref" href="#Part4"><b>10.1</b></a><ul class="ind">
     2228                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a></li>
    22282229                     </ul>
    22292230                  </li>
    2230                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9.1</b></a><ul class="ind">
     2231                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind">
    22312232                        <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
    22322233                     </ul>
    22332234                  </li>
    2234                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">
    2235                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li>
    2236                         <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.1</a></li>
     2235                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.1</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind">
     2236                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li>
     2237                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">5.1</a></li>
    22372238                     </ul>
    22382239                  </li>
    2239                   <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">1.1</a></li>
     2240                  <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">3</a></li>
    22402241               </ul>
    22412242            </li>
    22422243            <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
    2243                   <li class="indline1">representation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">1.1</a></li>
    2244                   <li class="indline1"><em>RFC1864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1864.1">5.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">5.8</a>, <a class="iref" href="#RFC1864"><b>9.1</b></a></li>
    2245                   <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
    2246                   <li class="indline1"><em>RFC1950</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1950.1">6.2</a>, <a class="iref" href="#RFC1950"><b>9.1</b></a></li>
    2247                   <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>
    2248                   <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>
    2249                   <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
    2250                   <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
    2251                         <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>
     2244                  <li class="indline1">representation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">4</a></li>
     2245                  <li class="indline1"><em>RFC1864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1864.1">6.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">6.8</a>, <a class="iref" href="#RFC1864"><b>10.1</b></a></li>
     2246                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
     2247                  <li class="indline1"><em>RFC1950</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1950.1">7.2</a>, <a class="iref" href="#RFC1950"><b>10.1</b></a></li>
     2248                  <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">7.2</a>, <a class="iref" href="#RFC1951"><b>10.1</b></a></li>
     2249                  <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">7.2</a>, <a class="iref" href="#RFC1952"><b>10.1</b></a></li>
     2250                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
     2251                  <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">4.2</a>, <a class="iref" href="#RFC2046"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
     2252                        <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">4.2</a></li>
    22522253                        <li class="indline1"><em>Section 5.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a></li>
    22532254                     </ul>
    22542255                  </li>
    2255                   <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<a class="iref" href="#RFC2049"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">
     2256                  <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<a class="iref" href="#RFC2049"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">
    22562257                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li>
    22572258                     </ul>
    22582259                  </li>
    2259                   <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">9.1</a>, <a class="iref" href="#RFC2068"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li>
    2260                   <li class="indline1"><em>RFC2076</em>&nbsp;&nbsp;<a class="iref" href="#RFC2076"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>
    2261                   <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>9.1</b></a></li>
    2262                   <li class="indline1"><em>RFC2183</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.1">7.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">7.2</a>, <a class="iref" href="#RFC2183"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind">
    2263                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.2">7.2</a></li>
     2260                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">10.1</a>, <a class="iref" href="#RFC2068"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li>
     2261                  <li class="indline1"><em>RFC2076</em>&nbsp;&nbsp;<a class="iref" href="#RFC2076"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>
     2262                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>10.1</b></a></li>
     2263                  <li class="indline1"><em>RFC2183</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.1">8.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">8.2</a>, <a class="iref" href="#RFC2183"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind">
     2264                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.2">8.2</a></li>
    22642265                     </ul>
    22652266                  </li>
    2266                   <li class="indline1"><em>RFC2277</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9.2</b></a></li>
    2267                   <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>
    2268                   <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li>
    2269                   <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a>, <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind">
    2270                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a></li>
     2267                  <li class="indline1"><em>RFC2277</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>10.2</b></a></li>
     2268                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">5</a>, <a class="iref" href="#RFC2295"><b>10.2</b></a></li>
     2269                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>10.2</b></a></li>
     2270                  <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">6.7</a>, <a class="iref" href="#RFC2557"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind">
     2271                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">6.7</a></li>
    22712272                     </ul>
    22722273                  </li>
    2273                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">5.4</a>, <a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">
    2274                         <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">5.4</a></li>
     2274                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">6.4</a>, <a class="iref" href="#RFC2616"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">
     2275                        <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">6.4</a></li>
    22752276                     </ul>
    22762277                  </li>
    2277                   <li class="indline1"><em>RFC3629</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b>9.2</b></a></li>
    2278                   <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">6.1</a>, <a class="iref" href="#RFC3864"><b>9.2</b></a></li>
    2279                   <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b>9.2</b></a></li>
    2280                   <li class="indline1"><em>RFC4647</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">5.4</a>, <a class="iref" href="#RFC4647"><b>9.1</b></a><ul class="ind">
    2281                         <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">5.4</a></li>
    2282                         <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.2">5.4</a></li>
    2283                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.3">5.4</a></li>
    2284                         <li class="indline1"><em>Section 3.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.4">5.4</a></li>
     2278                  <li class="indline1"><em>RFC3629</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b>10.2</b></a></li>
     2279                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">7.1</a>, <a class="iref" href="#RFC3864"><b>10.2</b></a></li>
     2280                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b>10.2</b></a></li>
     2281                  <li class="indline1"><em>RFC4647</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">6.4</a>, <a class="iref" href="#RFC4647"><b>10.1</b></a><ul class="ind">
     2282                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">6.4</a></li>
     2283                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.2">6.4</a></li>
     2284                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.3">6.4</a></li>
     2285                        <li class="indline1"><em>Section 3.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.4">6.4</a></li>
    22852286                     </ul>
    22862287                  </li>
    2287                   <li class="indline1"><em>RFC5226</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b>9.2</b></a><ul class="ind">
     2288                  <li class="indline1"><em>RFC5226</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b>10.2</b></a><ul class="ind">
    22882289                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a></li>
    22892290                     </ul>
    22902291                  </li>
    2291                   <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b>9.1</b></a><ul class="ind">
     2292                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b>10.1</b></a><ul class="ind">
    22922293                        <li class="indline1"><em>Appendix B.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.2">1.3</a></li>
    22932294                     </ul>
    22942295                  </li>
    2295                   <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#RFC5322"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li>
    2296                   <li class="indline1"><em>RFC5646</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b>9.1</b></a><ul class="ind">
     2296                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#RFC5322"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li>
     2297                  <li class="indline1"><em>RFC5646</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b>10.1</b></a><ul class="ind">
    22972298                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.2">2.4</a></li>
    22982299                     </ul>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r964 r966  
    627627      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
    628628</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1>
    629       <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations from the same requested resource. HTTP/1.1 uses entity-tags
    630          in the ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
     629      <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations of the same resource. HTTP/1.1 uses entity-tags in the ETag
     630         (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
    631631      </p>
    632632      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a>
     
    642642      </p>
    643643      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2>
    644       <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):
     644      <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):
    645645      </p>
    646646      <div id="rfc.figure.u.4"></div>
     
    893893      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    894894      <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p>
    895       <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    896          receives the message.
    897       </p>
    898895      <div id="rfc.iref.e.1"></div>
    899896      <div id="rfc.iref.h.1"></div>
    900897      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    901       <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the Effective Request URI. An entity-tag is intended for use as a resource-local
     898      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local
    902899         identifier for differentiating between representations of the same resource that vary over time or via content negotiation
    903900         (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
     
    10631060      <div id="rfc.iref.h.6"></div>
    10641061      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2>
    1065       <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the representation
    1066          was last modified.
     1062      <p id="rfc.section.6.6.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the representation was last
     1063         modified.
    10671064      </p>
    10681065      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a>   = "Last-Modified" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.last-modified" class="smpl">Last-Modified-v</a>
     
    10841081      <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
    10851082      </p>
    1086       <p id="rfc.section.6.6.p.9">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered
    1087          to be valid if the representation has not been modified since the Last-Modified value.
     1083      <p id="rfc.section.6.6.p.9">The Last-Modified header field value is often used as a cache validator. In simple terms, a cache entry is considered to be
     1084         valid if the representation has not been modified since the Last-Modified value.
    10881085      </p>
    10891086      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     
    14501447                  </li>
    14511448                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a>, <a class="iref" href="#rfc.xref.Part3.2">2.1</a>, <a class="iref" href="#Part3"><b>10.1</b></a><ul class="ind">
    1452                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a></li>
    1453                         <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">2.1</a></li>
     1449                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a></li>
     1450                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">2.1</a></li>
    14541451                     </ul>
    14551452                  </li>
  • draft-ietf-httpbis/latest/p5-range.html

    r962 r966  
    676676         </li>
    677677      </ul>
    678       <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise, the response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
     678      <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.
    679679      </p>
    680680      <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
     
    690690         length of the selected resource.)
    691691      </p>
    692       <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range entity-header field specifying the current length of the selected resource (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.
     692      <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.
    693693      </p>
    694694      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1>
     
    710710      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    711711      <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to range requests and partial responses.</p>
    712       <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    713          receives the message.
    714       </p>
    715712      <div id="rfc.iref.a.1"></div>
    716713      <div id="rfc.iref.h.1"></div>
     
    732729      <div id="rfc.iref.h.2"></div>
    733730      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
    734       <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial representation to specify where in the full representation
    735          the partial body should be applied.
     731      <p id="rfc.section.5.2.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload
     732         body should be applied.
    736733      </p>
    737734      <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
     
    13511348         </li>
    13521349         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
    1353          </li>
    1354          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "Clarify entity / representation / variant terminology"
    13551350         </li>
    13561351         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
  • draft-ietf-httpbis/latest/p6-cache.html

    r964 r966  
    762762      </p>
    763763      <ul>
    764          <li>The presented Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
     764         <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
    765765         </li>
    766766         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
     
    946946         <li>POST</li>
    947947      </ul>
    948       <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    949       </p>
    950       <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    951       </p>
    952       <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
     948      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     949      </p>
     950      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     951      </p>
     952      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will
    953953         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
    954954      </p>
     
    10121012      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    10131013      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    1014       <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1015          receives the message.
    1016       </p>
    10171014      <div id="rfc.iref.a.2"></div>
    10181015      <div id="rfc.iref.h.2"></div>
     
    12571254      <div id="rfc.iref.h.4"></div>
    12581255      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1259       <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
     1256      <p id="rfc.section.3.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
    12601257      </p>
    12611258      <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
     
    18991896      <p id="rfc.section.C.12.p.1">Closed issues: </p>
    19001897      <ul>
     1898         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
     1899         </li>
    19011900         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
    19021901         </li>
  • draft-ietf-httpbis/latest/p7-auth.html

    r961 r966  
    613613      <div id="rfc.iref.s.1"></div>
    614614      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
    615       <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;3.4</a>) containing a challenge applicable to the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
     615      <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;3.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
    616616         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    617617         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
     
    622622      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
    623623      <p id="rfc.section.2.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The
    624          proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;3.2</a>) containing a challenge applicable to the proxy for the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
     624         proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;3.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
    625625      </p>
    626626      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     
    655655      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    656656      <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters
    657          applicable to the proxy for this Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
     657         applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
    658658      </p>
    659659      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>   = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a>
     
    683683      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    684684      <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)
    685          and parameters applicable to the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
     685         and parameters applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
    686686      </p>
    687687      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>   = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>
Note: See TracChangeset for help on using the changeset viewer.