Ignore:
Timestamp:
18/02/12 10:29:16 (9 years ago)
Author:
fielding@…
Message:

Move definitions of Transfer-Encoding and Content-Length to where
they are first used. Move other transfer encoding stuff (codings,
TE, and Trailers) to its own section. Moved text is unchanged.
Make Upgrade use protocol tokens instead of product tokens (WTF?)
and move product tokens to p2. Reduce protocol registry requirements.
Removed now-empty section on protocol parameters.

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r1494 r1538  
    6161Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS transfer-coding ] )
    6262URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
    63 Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
     63Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
    6464User-Agent = product *( RWS ( product / comment ) )
    6565Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) )
    … …  
    181181product = token [ "/" product-version ]
    182182product-version = token
     183protocol = protocol-name [ "/" protocol-version ]
    183184protocol-name = token
    184185protocol-version = token

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1537 r1538  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 20, 2012";
     462       content: "Expires August 21, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    486486      <link rel="Chapter" title="3 Message Format" href="#rfc.section.3">
    487487      <link rel="Chapter" title="4 Message Routing" href="#rfc.section.4">
    488       <link rel="Chapter" title="5 Protocol Parameters" href="#rfc.section.5">
     488      <link rel="Chapter" title="5 Transfer Codings" href="#rfc.section.5">
    489489      <link rel="Chapter" title="6 Connections" href="#rfc.section.6">
    490490      <link rel="Chapter" title="7 Miscellaneous notes that might disappear" href="#rfc.section.7">
    … …  
    510510      <meta name="dct.creator" content="Reschke, J. F.">
    511511      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    512       <meta name="dct.issued" scheme="ISO8601" content="2012-02-17">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-02-18">
    513513      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    542542            </tr>
    543543            <tr>
    544                <td class="left">Expires: August 20, 2012</td>
     544               <td class="left">Expires: August 21, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
    … …  
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">February 17, 2012</td>
     597               <td class="right">February 18, 2012</td>
    598598            </tr>
    599599         </tbody>
    … …  
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on August 20, 2012.</p>
     630      <p>This Internet-Draft will expire on August 21, 2012.</p>
    631631      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    632632      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    688688                  </ul>
    689689               </li>
    690                <li>3.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a></li>
     690               <li>3.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a><ul>
     691                     <li>3.3.1&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
     692                     <li>3.3.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
     693                     <li>3.3.3&nbsp;&nbsp;&nbsp;<a href="#message.body.length">Message Body Length</a></li>
     694                  </ul>
     695               </li>
    691696               <li>3.4&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></li>
    692697               <li>3.5&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li>
    … …  
    700705            </ul>
    701706         </li>
    702          <li>5.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
    703                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
    704                      <li>5.1.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
    705                      <li>5.1.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
    706                            <li>5.1.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
    707                            <li>5.1.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
    708                            <li>5.1.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    709                         </ul>
    710                      </li>
    711                      <li>5.1.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     707         <li>5.&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
     708               <li>5.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
     709               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
     710                     <li>5.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
     711                     <li>5.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
     712                     <li>5.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    712713                  </ul>
    713714               </li>
    714                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
    715                <li>5.3&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
     715               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     716               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a><ul>
     717                     <li>5.4.1&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
     718                  </ul>
     719               </li>
     720               <li>5.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    716721            </ul>
    717722         </li>
    … …  
    752757         <li>8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    753758               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    754                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
    755                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    756                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
    757                <li>8.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    758                <li>8.6&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
    759                <li>8.7&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    760                      <li>8.7.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
     759               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
     760               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
     761                     <li>8.3.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    761762                  </ul>
    762763               </li>
    763                <li>8.8&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     764               <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    764765            </ul>
    765766         </li>
    … …  
    993994         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    994995         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    995          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
     996         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.4</a>) header fields for both connections.
    996997      </p>
    997998      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    12911292  <a href="#header.fields" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12921293</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1293          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1294         the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12941295      </p>
    12951296      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    … …  
    13761377      <div id="rule.token.separators">
    13771378         <p id="rfc.section.3.2.4.p.1">        Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.
    1378             These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
     1379            These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>).
    13791380         </p>
    13801381      </div>
    … …  
    14541455      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    14551456</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    1456          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.6</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
    1457       </p>
    1458       <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
    1459          field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>.
    1460       </p>
    1461       <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
     1457         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
     1458      </p>
     1459      <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
     1460      <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
     1461         in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
     1462         message framing algorithm to be independent of method semantics.
     1463      </p>
     1464      <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
     1465         the response status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
     1466         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
     1467         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
     1468      </p>
     1469      <div id="rfc.iref.t.4"></div>
     1470      <div id="rfc.iref.h.6"></div>
     1471      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3>
     1472      <p id="rfc.section.3.3.1.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
     1473         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.2"><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
     1474         are not.
     1475      </p>
     1476      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
     1477</pre><p id="rfc.section.3.3.1.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>. An example is:
     1478      </p>
     1479      <div id="rfc.figure.u.35"></div><pre class="text">  Transfer-Encoding: chunked
     1480</pre><p id="rfc.section.3.3.1.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.
     1481      </p>
     1482      <p id="rfc.section.3.3.1.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
     1483      <p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
     1484      </p>
     1485      <p id="rfc.section.3.3.1.p.8">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
     1486         field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
     1487      </p>
     1488      <div id="rfc.iref.c.6"></div>
     1489      <div id="rfc.iref.h.7"></div>
     1490      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h3>
     1491      <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
     1492         than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
     1493         indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
     1494         been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload
     1495         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
     1496      </p>
     1497      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     1498</pre><p id="rfc.section.3.3.2.p.3">An example is</p>
     1499      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Length: 3495
     1500</pre><p id="rfc.section.3.3.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
     1501         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
     1502      </p>
     1503      <p id="rfc.section.3.3.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
     1504      <p id="rfc.section.3.3.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
     1505         an optional field used within the "message/external-body" content-type.
     1506      </p>
     1507      <p id="rfc.section.3.3.2.p.8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
    14621508         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    14631509         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing
    14641510         that decimal value prior to determining the message-body length.
    14651511      </p>
    1466       <p id="rfc.section.3.3.p.6">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    1467       <p id="rfc.section.3.3.p.7">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1468          in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
    1469          message framing algorithm to be independent of method semantics.
    1470       </p>
    1471       <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
    1472          the response status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
    1473          Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1474          All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
    1475       </p>
    1476       <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p>
    1477       <p id="rfc.section.3.3.p.10"> </p>
     1512      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
     1513      <p id="rfc.section.3.3.3.p.1">The length of the message-body is determined by one of the following (in order of precedence):</p>
     1514      <p id="rfc.section.3.3.3.p.2"> </p>
    14781515      <ol>
    14791516         <li>
    … …  
    14831520         </li>
    14841521         <li>
    1485             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1522            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
    14861523               indicates the data is complete.
    14871524            </p>
    … …  
    15201557         </li>
    15211558      </ol>
    1522       <p id="rfc.section.3.3.p.11">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
     1559      <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
    15231560         by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
    15241561         with HTTP/1.0.
    15251562      </p>
    1526       <p id="rfc.section.3.3.p.12">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
    1527       </p>
    1528       <p id="rfc.section.3.3.p.13">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,
     1563      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
     1564      </p>
     1565      <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,
    15291566         since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the
    15301567         chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in
    15311568         advance of being called and the server is unable or unwilling to buffer the entire request before processing.
    15321569      </p>
    1533       <p id="rfc.section.3.3.p.14">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
     1570      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
    15341571         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
    15351572      </p>
    … …  
    15811618         </p>
    15821619      </div>
    1583       <div id="rfc.figure.u.34"></div><pre>http://www.example.org/where?q=now
     1620      <div id="rfc.figure.u.38"></div><pre>http://www.example.org/where?q=now
    15841621</pre><p id="rfc.section.4.1.p.4">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
    15851622         lines:
    15861623      </p>
    1587       <div id="rfc.figure.u.35"></div><pre class="text2">GET /where?q=now HTTP/1.1
     1624      <div id="rfc.figure.u.39"></div><pre class="text2">GET /where?q=now HTTP/1.1
    15881625Host: www.example.org
    15891626</pre><p id="rfc.section.4.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
    … …  
    15991636         </p>
    16001637      </div>
    1601       <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1638      <div id="rfc.figure.u.40"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    16021639</pre><p id="rfc.section.4.1.p.10">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.
    16031640      </p>
    … …  
    16081645         </p>
    16091646      </div>
    1610       <div id="rfc.figure.u.37"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     1647      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    16111648</pre><div id="asterix-form">
    16121649         <p id="rfc.section.4.1.p.14"><span id="rfc.iref.a.4"></span> The asterisk ("*") form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
    … …  
    16141651         </p>
    16151652      </div>
    1616       <div id="rfc.figure.u.38"></div><pre class="text2">OPTIONS * HTTP/1.1
     1653      <div id="rfc.figure.u.42"></div><pre class="text2">OPTIONS * HTTP/1.1
    16171654</pre><p id="rfc.section.4.1.p.16">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
    16181655         no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server.
    16191656      </p>
    1620       <div id="rfc.figure.u.39"></div>
     1657      <div id="rfc.figure.u.43"></div>
    16211658      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1622 </pre><div id="rfc.figure.u.40"></div>
     1659</pre><div id="rfc.figure.u.44"></div>
    16231660      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    16241661Host: www.example.org:8001
    … …  
    16491686      </p>
    16501687      <div id="rfc.iref.e.1"></div>
    1651       <div id="rfc.iref.t.4"></div>
     1688      <div id="rfc.iref.t.5"></div>
    16521689      <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>
    16531690      <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
    … …  
    16651702         </li>
    16661703         <li>the octet sequence "://",</li>
    1667          <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;8.3</a>), and
     1704         <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;8.2</a>), and
    16681705         </li>
    16691706         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
    … …  
    16731710      </p>
    16741711      <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    1675       <div id="rfc.figure.u.41"></div>
     1712      <div id="rfc.figure.u.45"></div>
    16761713      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    16771714Host: www.example.org:8080
    … …  
    16791716         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    16801717      </p>
    1681       <div id="rfc.figure.u.42"></div>
     1718      <div id="rfc.figure.u.46"></div>
    16821719      <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
    16831720Host: www.example.org
    … …  
    16951732      <p id="rfc.section.4.4.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
    16961733      </p>
    1697       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    1698       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    1699       <p id="rfc.section.5.1.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
     1734      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
     1735      <p id="rfc.section.5.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
    17001736         to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
    17011737         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    17021738      </p>
    1703       <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
    1704                           / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.1.2.1</a>
    1705                           / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.1.2.2</a>
    1706                           / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.1.2.3</a>
     1739      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>
     1740                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.1</a>
     1741                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2</a>
     1742                          / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.3</a>
    17071743                          / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    17081744  <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
    17091745</pre><div id="rule.parameter">
    1710          <p id="rfc.section.5.1.p.3">      Parameters are in the form of attribute/value pairs.</p>
     1746         <p id="rfc.section.5.p.3">      Parameters are in the form of attribute/value pairs.</p>
    17111747      </div>
    1712       <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
     1748      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
    17131749  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    17141750  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    1715 </pre><p id="rfc.section.5.1.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.6</a>).
    1716       </p>
    1717       <p id="rfc.section.5.1.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
     1751</pre><p id="rfc.section.5.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;5.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
     1752      </p>
     1753      <p id="rfc.section.5.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    17181754         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
    17191755         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
    17201756      </p>
    1721       <p id="rfc.section.5.1.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    1722       </p>
    1723       <div id="rfc.iref.c.6"></div>
     1757      <p id="rfc.section.5.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     1758      </p>
    17241759      <div id="rfc.iref.c.7"></div>
    1725       <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
    1726       <p id="rfc.section.5.1.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
     1760      <div id="rfc.iref.c.8"></div>
     1761      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2>
     1762      <p id="rfc.section.5.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
    17271763         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
    17281764         for the recipient to verify that it has received the full message.
    17291765      </p>
    1730       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1766      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    17311767                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    17321768                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
    … …  
    17481784                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    17491785  <a href="#chunked.encoding" class="smpl">qdtext-nf</a>      = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1750 </pre><p id="rfc.section.5.1.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
     1786</pre><p id="rfc.section.5.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    17511787         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    17521788      </p>
    1753       <p id="rfc.section.5.1.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
    1754          can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;8.5</a>).
    1755       </p>
    1756       <p id="rfc.section.5.1.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
     1789      <p id="rfc.section.5.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     1790         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;5.5</a>).
     1791      </p>
     1792      <p id="rfc.section.5.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
    17571793      </p>
    17581794      <ol>
    17591795         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
    1760             described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;8.4</a>; or,
     1796            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;5.4</a>; or,
    17611797         </li>
    17621798         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
    … …  
    17661802         </li>
    17671803      </ol>
    1768       <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
     1804      <p id="rfc.section.5.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    17691805         forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly
    17701806         infinite buffer on the proxy.
    17711807      </p>
    1772       <p id="rfc.section.5.1.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1773       <div id="rfc.figure.u.46"></div><pre class="text">  length := 0
     1808      <p id="rfc.section.5.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1809      <div id="rfc.figure.u.50"></div><pre class="text">  length := 0
    17741810  read chunk-size, chunk-ext (if any) and CRLF
    17751811  while (chunk-size &gt; 0) {
    … …  
    17861822  Content-Length := length
    17871823  Remove "chunked" from Transfer-Encoding
    1788 </pre><p id="rfc.section.5.1.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    1789       </p>
    1790       <p id="rfc.section.5.1.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged.
    1791       </p>
    1792       <p id="rfc.section.5.1.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
     1824</pre><p id="rfc.section.5.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1825      </p>
     1826      <p id="rfc.section.5.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged.
     1827      </p>
     1828      <p id="rfc.section.5.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
    17931829         messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding
    17941830         applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.
    17951831      </p>
    1796       <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
    1797       <p id="rfc.section.5.1.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
    1798       <div class="note" id="rfc.section.5.1.2.p.2">
     1832      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
     1833      <p id="rfc.section.5.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
     1834      <div class="note" id="rfc.section.5.2.p.2">
    17991835         <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
    18001836            Their use here is representative of historical practice, not good design.
    18011837         </p>
    18021838      </div>
    1803       <div class="note" id="rfc.section.5.1.2.p.3">
     1839      <div class="note" id="rfc.section.5.2.p.3">
    18041840         <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
    18051841         </p>
    18061842      </div>
    1807       <div id="rfc.iref.c.8"></div>
    18081843      <div id="rfc.iref.c.9"></div>
    1809       <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
    1810       <p id="rfc.section.5.1.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
     1844      <div id="rfc.iref.c.10"></div>
     1845      <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h3>
     1846      <p id="rfc.section.5.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    18111847         coding (LZW).
    18121848      </p>
    18131849      <div id="rfc.iref.d.2"></div>
    1814       <div id="rfc.iref.c.10"></div>
    1815       <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
    1816       <p id="rfc.section.5.1.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
    1817       </p>
    1818       <div class="note" id="rfc.section.5.1.2.2.p.2">
     1850      <div id="rfc.iref.c.11"></div>
     1851      <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h3>
     1852      <p id="rfc.section.5.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
     1853      </p>
     1854      <div class="note" id="rfc.section.5.2.2.p.2">
    18191855         <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper.
    18201856         </p>
    18211857      </div>
    1822       <div id="rfc.iref.g.70"></div>
    1823       <div id="rfc.iref.c.11"></div>
    1824       <h4 id="rfc.section.5.1.2.3"><a href="#rfc.section.5.1.2.3">5.1.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
    1825       <p id="rfc.section.5.1.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    1826       </p>
    1827       <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>
    1828       <p id="rfc.section.5.1.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
    1829       <p id="rfc.section.5.1.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     1858      <div id="rfc.iref.g.72"></div>
     1859      <div id="rfc.iref.c.12"></div>
     1860      <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3>
     1861      <p id="rfc.section.5.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
     1862      </p>
     1863      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2>
     1864      <p id="rfc.section.5.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
     1865      <p id="rfc.section.5.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    18301866      </p>
    18311867      <ul>
    … …  
    18341870         <li>Pointer to specification text</li>
    18351871      </ul>
    1836       <p id="rfc.section.5.1.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.2"><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;5.1.2</a>).
    1837       </p>
    1838       <p id="rfc.section.5.1.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.
    1839       </p>
    1840       <p id="rfc.section.5.1.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    1841       </p>
    1842       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    1843       <p id="rfc.section.5.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
    1844          using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace.
    1845          By convention, the products are listed in order of their significance for identifying the application.
    1846       </p>
    1847       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    1848   <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    1849 </pre><p id="rfc.section.5.2.p.3">Examples:</p>
    1850       <div id="rfc.figure.u.48"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    1851   Server: Apache/0.8.4
    1852 </pre><p id="rfc.section.5.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
    1853       </p>
    1854       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1855       <p id="rfc.section.5.3.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;8.4</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.3"><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
     1872      <p id="rfc.section.5.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.3"><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;5.2</a>).
     1873      </p>
     1874      <p id="rfc.section.5.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.
     1875      </p>
     1876      <p id="rfc.section.5.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     1877      </p>
     1878      <div id="rfc.iref.t.6"></div>
     1879      <div id="rfc.iref.h.8"></div>
     1880      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     1881      <p id="rfc.section.5.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
     1882         or not it is willing to accept trailer fields in a chunked transfer-coding.
     1883      </p>
     1884      <p id="rfc.section.5.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     1885         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>).
     1886      </p>
     1887      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     1888  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
     1889  <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
     1890  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
     1891</pre><p id="rfc.section.5.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     1892         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     1893      </p>
     1894      <p id="rfc.section.5.4.p.5">Examples of its use are:</p>
     1895      <div id="rfc.figure.u.52"></div><pre class="text">  TE: deflate
     1896  TE:
     1897  TE: trailers, deflate;q=0.5
     1898</pre><p id="rfc.section.5.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
     1899      </p>
     1900      <p id="rfc.section.5.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     1901      <ol>
     1902         <li>
     1903            <p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing
     1904               to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that,
     1905               if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response,
     1906               or that it will attempt to buffer the response on behalf of downstream recipients.
     1907            </p>
     1908            <p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering
     1909               the entire response.
     1910            </p>
     1911         </li>
     1912         <li>
     1913            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
     1914               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.4.1</a>, a qvalue of 0 means "not acceptable".)
     1915            </p>
     1916         </li>
     1917         <li>
     1918            <p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred.
     1919               The "chunked" transfer-coding always has a qvalue of 1.
     1920            </p>
     1921         </li>
     1922      </ol>
     1923      <p id="rfc.section.5.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
     1924         no transfer-coding is always acceptable.
     1925      </p>
     1926      <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
     1927      <p id="rfc.section.5.4.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;5.4</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.4"><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
    18561928         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
    18571929         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.
    18581930      </p>
    1859       <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1931      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18601932                 / ( "1" [ "." 0*3("0") ] )
    1861 </pre><div class="note" id="rfc.section.5.3.p.3">
     1933</pre><div class="note" id="rfc.section.5.4.1.p.3">
    18621934         <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
    18631935         </p>
    18641936      </div>
     1937      <div id="rfc.iref.t.7"></div>
     1938      <div id="rfc.iref.h.9"></div>
     1939      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     1940      <p id="rfc.section.5.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
     1941         chunked transfer-coding.
     1942      </p>
     1943      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.78"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     1944</pre><p id="rfc.section.5.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
     1945         to know which header fields to expect in the trailer.
     1946      </p>
     1947      <p id="rfc.section.5.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     1948      </p>
     1949      <p id="rfc.section.5.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
     1950      </p>
     1951      <ul>
     1952         <li>Transfer-Encoding</li>
     1953         <li>Content-Length</li>
     1954         <li>Trailer</li>
     1955      </ul>
    18651956      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    18661957      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    … …  
    18951986      </p>
    18961987      <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    1897          takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     1988         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    18981989      </p>
    18991990      <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    … …  
    19212012      </p>
    19222013      <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
    1923       <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;8.1</a>.
     2014      <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>.
    19242015      </p>
    19252016      <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
    … …  
    19502041      </ul>
    19512042      <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
    1952       <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>).
     2043      <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;8.1</a>).
    19532044      </p>
    19542045      <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
    … …  
    19872078         </p>
    19882079      </div>
    1989       <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><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;5.1</a>).
     2080      <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><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;5</a>).
    19902081      </p>
    19912082      <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    … …  
    20262117      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    20272118      <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    2028          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
     2119         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    20292120      </p>
    20302121      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.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>
    … …  
    20362127      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    20372128      <ul>
    2038          <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 header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2039          </li>
    2040          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><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.
     2129         <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 header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2130         </li>
     2131         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><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.
    20412132         </li>
    20422133      </ul>
    … …  
    21202211               <tr>
    21212212                  <td class="left">Connection</td>
    2122                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;8.1</a></td>
     2213                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a></td>
    21232214               </tr>
    21242215               <tr>
    21252216                  <td class="left">Content-Length</td>
    2126                   <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;8.2</a></td>
     2217                  <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a></td>
    21272218               </tr>
    21282219               <tr>
    21292220                  <td class="left">Host</td>
    2130                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.3</a></td>
     2221                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.2</a></td>
    21312222               </tr>
    21322223               <tr>
    21332224                  <td class="left">TE</td>
    2134                   <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;8.4</a></td>
     2225                  <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;5.4</a></td>
    21352226               </tr>
    21362227               <tr>
    21372228                  <td class="left">Trailer</td>
    2138                   <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.5</a></td>
     2229                  <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;5.5</a></td>
    21392230               </tr>
    21402231               <tr>
    21412232                  <td class="left">Transfer-Encoding</td>
    2142                   <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.6</a></td>
     2233                  <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;3.3.1</a></td>
    21432234               </tr>
    21442235               <tr>
    21452236                  <td class="left">Upgrade</td>
    2146                   <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.7</a></td>
     2237                  <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.3</a></td>
    21472238               </tr>
    21482239               <tr>
    21492240                  <td class="left">Via</td>
    2150                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.8</a></td>
     2241                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.4</a></td>
    21512242               </tr>
    21522243            </tbody>
    21532244         </table>
    21542245      </div>
    2155       <div id="rfc.iref.c.12"></div>
    2156       <div id="rfc.iref.h.6"></div>
     2246      <div id="rfc.iref.c.13"></div>
     2247      <div id="rfc.iref.h.10"></div>
    21572248      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    21582249      <p id="rfc.section.8.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
    … …  
    21642255      </p>
    21652256      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
    2166       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2257      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    21672258  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21682259</pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
    … …  
    21872278         of the response. For example,
    21882279      </p>
    2189       <div id="rfc.figure.u.51"></div><pre class="text">  Connection: close
     2280      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    21902281</pre><p id="rfc.section.8.1.p.10">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>) after the current request/response is complete.
    21912282      </p>
    … …  
    21942285      <p id="rfc.section.8.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
    21952286      </p>
    2196       <div id="rfc.iref.c.13"></div>
    2197       <div id="rfc.iref.h.7"></div>
    2198       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    2199       <p id="rfc.section.8.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
    2200          than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
    2201          indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
    2202          been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload
    2203          body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    2204       </p>
    2205       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    2206 </pre><p id="rfc.section.8.2.p.3">An example is</p>
    2207       <div id="rfc.figure.u.53"></div><pre class="text">  Content-Length: 3495
    2208 </pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    2209          can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
    2210       </p>
    2211       <p id="rfc.section.8.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
    2212       <p id="rfc.section.8.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
    2213          an optional field used within the "message/external-body" content-type.
    2214       </p>
    2215       <div id="rfc.iref.h.8"></div>
    2216       <div id="rfc.iref.h.9"></div>
    2217       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    2218       <p id="rfc.section.8.3.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
     2287      <div id="rfc.iref.h.11"></div>
     2288      <div id="rfc.iref.h.12"></div>
     2289      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
     2290      <p id="rfc.section.8.2.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
    22192291         server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
    22202292         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line.
    22212293      </p>
    2222       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
    2223 </pre><p id="rfc.section.8.3.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
     2294      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.81"></span>  <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>
     2295</pre><p id="rfc.section.8.2.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
    22242296         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    22252297      </p>
    2226       <p id="rfc.section.8.3.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    2227       <div id="rfc.figure.u.55"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2298      <p id="rfc.section.8.2.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
     2299      <div id="rfc.figure.u.58"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    22282300Host: www.example.org
    2229 </pre><p id="rfc.section.8.3.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
     2301</pre><p id="rfc.section.8.2.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
    22302302         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    22312303      </p>
    2232       <p id="rfc.section.8.3.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
     2304      <p id="rfc.section.8.2.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
    22332305         a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.
    22342306      </p>
    2235       <p id="rfc.section.8.3.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
     2307      <p id="rfc.section.8.2.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    22362308         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    22372309         relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
    22382310         cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
    22392311      </p>
    2240       <p id="rfc.section.8.3.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
     2312      <p id="rfc.section.8.2.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
    22412313         message that contains more than one Host header field or a Host header field with an invalid field-value.
    22422314      </p>
    2243       <p id="rfc.section.8.3.p.10">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="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
    2244       </p>
    2245       <div id="rfc.iref.t.5"></div>
    2246       <div id="rfc.iref.h.10"></div>
    2247       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    2248       <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
    2249          or not it is willing to accept trailer fields in a chunked transfer-coding.
    2250       </p>
    2251       <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    2252          accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>).
    2253       </p>
    2254       <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    2255   <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
    2256   <a href="#header.te" class="smpl">te-params</a> = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    2257   <a href="#header.te" class="smpl">te-ext</a>    = <a href="#header.fields" class="smpl">OWS</a> ";" <a href="#header.fields" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    2258 </pre><p id="rfc.section.8.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    2259          as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    2260       </p>
    2261       <p id="rfc.section.8.4.p.5">Examples of its use are:</p>
    2262       <div id="rfc.figure.u.57"></div><pre class="text">  TE: deflate
    2263   TE:
    2264   TE: trailers, deflate;q=0.5
    2265 </pre><p id="rfc.section.8.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
    2266       </p>
    2267       <p id="rfc.section.8.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    2268       <ol>
    2269          <li>
    2270             <p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing
    2271                to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that,
    2272                if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response,
    2273                or that it will attempt to buffer the response on behalf of downstream recipients.
    2274             </p>
    2275             <p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering
    2276                the entire response.
    2277             </p>
    2278          </li>
    2279          <li>
    2280             <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    2281                is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3</a>, a qvalue of 0 means "not acceptable".)
    2282             </p>
    2283          </li>
    2284          <li>
    2285             <p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred.
    2286                The "chunked" transfer-coding always has a qvalue of 1.
    2287             </p>
    2288          </li>
    2289       </ol>
    2290       <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
    2291          no transfer-coding is always acceptable.
    2292       </p>
    2293       <div id="rfc.iref.t.6"></div>
    2294       <div id="rfc.iref.h.11"></div>
    2295       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    2296       <p id="rfc.section.8.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
    2297          chunked transfer-coding.
    2298       </p>
    2299       <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    2300 </pre><p id="rfc.section.8.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    2301          to know which header fields to expect in the trailer.
    2302       </p>
    2303       <p id="rfc.section.8.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
    2304       </p>
    2305       <p id="rfc.section.8.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    2306       </p>
    2307       <ul>
    2308          <li>Transfer-Encoding</li>
    2309          <li>Content-Length</li>
    2310          <li>Trailer</li>
    2311       </ul>
    2312       <div id="rfc.iref.t.7"></div>
    2313       <div id="rfc.iref.h.12"></div>
    2314       <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    2315       <p id="rfc.section.8.6.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
    2316          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.5"><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
    2317          are not.
    2318       </p>
    2319       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.83"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    2320 </pre><p id="rfc.section.8.6.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.1</a>. An example is:
    2321       </p>
    2322       <div id="rfc.figure.u.60"></div><pre class="text">  Transfer-Encoding: chunked
    2323 </pre><p id="rfc.section.8.6.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.
    2324       </p>
    2325       <p id="rfc.section.8.6.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
     2315      <p id="rfc.section.8.2.p.10">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="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
     2316      </p>
    23262317      <div id="rfc.iref.u.5"></div>
    23272318      <div id="rfc.iref.h.13"></div>
    2328       <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2329       <p id="rfc.section.8.7.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2319      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2320      <p id="rfc.section.8.3.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    23302321         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23312322      </p>
    2332       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    2333 </pre><p id="rfc.section.8.7.p.3">For example,</p>
    2334       <div id="rfc.figure.u.62"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2335 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
     2323      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.82"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>  = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     2324
     2325  <a href="#header.upgrade" class="smpl">protocol</a> = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>]
     2326  <a href="#header.upgrade" class="smpl">protocol-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
     2327  <a href="#header.upgrade" class="smpl">protocol-version</a>  = <a href="#rule.token.separators" class="smpl">token</a>
     2328</pre><p id="rfc.section.8.3.p.3">For example,</p>
     2329      <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2330</pre><p id="rfc.section.8.3.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    23362331         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    23372332         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    23402335         the server, possibly according to the nature of the request method or target resource).
    23412336      </p>
    2342       <p id="rfc.section.8.7.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2337      <p id="rfc.section.8.3.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    23432338         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    23442339         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    23452340         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    23462341      </p>
    2347       <p id="rfc.section.8.7.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2348       </p>
    2349       <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2342      <p id="rfc.section.8.3.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2343      </p>
     2344      <p id="rfc.section.8.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    23502345         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23512346      </p>
    2352       <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     2347      <p id="rfc.section.8.3.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    23532348         to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    23542349      </p>
    2355       <p id="rfc.section.8.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2350      <p id="rfc.section.8.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    23562351         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    23572352         below.
    23582353      </p>
    2359       <h3 id="rfc.section.8.7.1"><a href="#rfc.section.8.7.1">8.7.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    2360       <p id="rfc.section.8.7.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
    2361          field. Each registered token is associated with contact information and an optional set of specifications that details how
    2362          the connection will be processed after it has been upgraded.
    2363       </p>
    2364       <p id="rfc.section.8.7.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
     2354      <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
     2355      <p id="rfc.section.8.3.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
     2356         header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
     2357         details how the connection will be processed after it has been upgraded.
     2358      </p>
     2359      <p id="rfc.section.8.3.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
    23652360      </p>
    23662361      <ol>
    2367          <li>A token, once registered, stays registered forever.</li>
     2362         <li>A protocol-name token, once registered, stays registered forever.</li>
    23682363         <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration.
    23692364         </li>
    … …  
    23722367         <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available.
    23732368         </li>
     2369         <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration.
     2370         </li>
    23742371         <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
    23752372         </li>
    2376          <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered.
    2377          </li>
    2378          <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted.
     2373         <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot
     2374            be contacted.
    23792375         </li>
    23802376      </ol>
    23812377      <div id="rfc.iref.v.1"></div>
    23822378      <div id="rfc.iref.h.14"></div>
    2383       <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2384       <p id="rfc.section.8.8.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
     2379      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
     2380      <p id="rfc.section.8.4.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
    23852381         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    23862382         systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    23872383         of all senders along the request/response chain.
    23882384      </p>
    2389       <div id="rfc.figure.u.63"></div><pre class="inline"><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><span id="rfc.iref.g.90"></span>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
     2385      <div id="rfc.figure.u.61"></div><pre class="inline"><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>  <a href="#header.via" class="smpl">Via</a>               = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    23902386                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    2391   <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a>
    2392   <a href="#header.via" class="smpl">protocol-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
    2393   <a href="#header.via" class="smpl">protocol-version</a>  = <a href="#rule.token.separators" class="smpl">token</a>
     2387  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
    23942388  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    23952389  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    2396 </pre><p id="rfc.section.8.8.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     2390</pre><p id="rfc.section.8.4.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    23972391         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    23982392         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    23992393      </p>
    2400       <p id="rfc.section.8.8.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     2394      <p id="rfc.section.8.4.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    24012395         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    24022396         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    24032397      </p>
    2404       <p id="rfc.section.8.8.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    2405       </p>
    2406       <p id="rfc.section.8.8.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
     2398      <p id="rfc.section.8.4.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     2399      </p>
     2400      <p id="rfc.section.8.4.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    24072401         fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    24082402      </p>
    2409       <p id="rfc.section.8.8.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     2403      <p id="rfc.section.8.4.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    24102404         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    24112405         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    24122406      </p>
    2413       <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2414 </pre><p id="rfc.section.8.8.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     2407      <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2408</pre><p id="rfc.section.8.4.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    24152409         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    24162410      </p>
    2417       <p id="rfc.section.8.8.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
     2411      <p id="rfc.section.8.4.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
    24182412         For example,
    24192413      </p>
    2420       <div id="rfc.figure.u.65"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2421 </pre><p id="rfc.section.8.8.p.12">could be collapsed to</p>
    2422       <div id="rfc.figure.u.66"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2423 </pre><p id="rfc.section.8.8.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     2414      <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2415</pre><p id="rfc.section.8.4.p.12">could be collapsed to</p>
     2416      <div id="rfc.figure.u.64"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2417</pre><p id="rfc.section.8.4.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    24242418         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    24252419      </p>
    … …  
    24512445                  <td class="left">http</td>
    24522446                  <td class="left">standard</td>
    2453                   <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section&nbsp;8.2</a>
     2447                  <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section&nbsp;3.3.2</a>
    24542448                  </td>
    24552449               </tr>
    … …  
    24582452                  <td class="left">http</td>
    24592453                  <td class="left">standard</td>
    2460                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.3</a>
     2454                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.2</a>
    24612455                  </td>
    24622456               </tr>
    … …  
    24652459                  <td class="left">http</td>
    24662460                  <td class="left">standard</td>
    2467                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;8.4</a>
     2461                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;5.4</a>
    24682462                  </td>
    24692463               </tr>
    … …  
    24722466                  <td class="left">http</td>
    24732467                  <td class="left">standard</td>
    2474                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;8.5</a>
     2468                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;5.5</a>
    24752469                  </td>
    24762470               </tr>
    … …  
    24792473                  <td class="left">http</td>
    24802474                  <td class="left">standard</td>
    2481                   <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.6</a>
     2475                  <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;3.3.1</a>
    24822476                  </td>
    24832477               </tr>
    … …  
    24862480                  <td class="left">http</td>
    24872481                  <td class="left">standard</td>
    2488                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.7</a>
     2482                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.3</a>
    24892483                  </td>
    24902484               </tr>
    … …  
    24932487                  <td class="left">http</td>
    24942488                  <td class="left">standard</td>
    2495                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.8</a>
     2489                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.4</a>
    24962490                  </td>
    24972491               </tr>
    … …  
    26422636      </dl>
    26432637      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
    2644       <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.1.3</a> of this document.
     2638      <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.3</a> of this document.
    26452639      </p>
    26462640      <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    … …  
    26602654                  <td class="left">chunked</td>
    26612655                  <td class="left">Transfer in a series of chunks</td>
    2662                   <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>
     2656                  <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>
    26632657                  </td>
    26642658               </tr>
    … …  
    26662660                  <td class="left">compress</td>
    26672661                  <td class="left">UNIX "compress" program method</td>
    2668                   <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.1.2.1</a>
     2662                  <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.1</a>
    26692663                  </td>
    26702664               </tr>
    … …  
    26732667                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    26742668                  </td>
    2675                   <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.1.2.2</a>
     2669                  <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2</a>
    26762670                  </td>
    26772671               </tr>
    … …  
    26792673                  <td class="left">gzip</td>
    26802674                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    2681                   <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.1.2.3</a>
     2675                  <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.3</a>
    26822676                  </td>
    26832677               </tr>
    … …  
    26862680      </div>
    26872681      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2688       <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.7.1</a> of this document.
     2682      <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.3.1</a> of this document.
    26892683      </p>
    26902684      <p id="rfc.section.9.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    … …  
    30373031      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30383032      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3>
    3039       <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;8.3</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
     3033      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;8.2</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30403034      </p>
    30413035      <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    30813075      <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
    30823076      </p>
    3083       <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5.1</a>)
     3077      <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5</a>)
    30843078      </p>
    30853079      <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    … …  
    30873081      </p>
    30883082      <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
    3089          disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>)
     3083         disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>)
    30903084      </p>
    30913085      <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    … …  
    30983092      <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;8.1</a>)
    30993093      </p>
    3100       <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.7</a>)
     3094      <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.3</a>)
    31013095      </p>
    31023096      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3103       <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     3097      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    31043098
    31053099<a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
    … …  
    31313125
    31323126<a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in [RFC3986], Section 4.1&gt;
    3133 <a href="#header.upgrade" class="smpl">Upgrade</a> = *( "," OWS ) product *( OWS "," [ OWS product ] )
     3127<a href="#header.upgrade" class="smpl">Upgrade</a> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
    31343128
    31353129<a href="#header.via" class="smpl">Via</a> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
    … …  
    31733167<a href="#uri" class="smpl">path-absolute</a> = &lt;path-absolute, defined in [RFC3986], Section 3.3&gt;
    31743168<a href="#uri" class="smpl">port</a> = &lt;port, defined in [RFC3986], Section 3.2.3&gt;
    3175 <a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ]
    3176 <a href="#product.tokens" class="smpl">product-version</a> = token
    3177 <a href="#header.via" class="smpl">protocol-name</a> = token
    3178 <a href="#header.via" class="smpl">protocol-version</a> = token
     3169<a href="#header.upgrade" class="smpl">protocol</a> = protocol-name [ "/" protocol-version ]
     3170<a href="#header.upgrade" class="smpl">protocol-name</a> = token
     3171<a href="#header.upgrade" class="smpl">protocol-version</a> = token
    31793172<a href="#header.via" class="smpl">pseudonym</a> = token
    31803173
    … …  
    32193212
    32203213<a href="#rule.token.separators" class="smpl">word</a> = token / quoted-string
    3221 </pre> <div id="rfc.figure.u.68"></div>
     3214</pre> <div id="rfc.figure.u.66"></div>
    32223215      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
    32233216; Connection defined but not used
    … …  
    36363629                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
    36373630                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    3638                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">5.1.1</a></li>
     3631                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.1</a></li>
    36393632                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    36403633                  <li>Coding Format&nbsp;&nbsp;
    36413634                     <ul>
    3642                         <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.1.1</a></li>
    3643                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.1.2.1</a></li>
    3644                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.1.2.2</a></li>
    3645                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.1.2.3</a></li>
     3635                        <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1</a></li>
     3636                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.2.1</a></li>
     3637                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.2.2</a></li>
     3638                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.12">5.2.3</a></li>
    36463639                     </ul>
    36473640                  </li>
    3648                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1.2.1</a></li>
     3641                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.2.1</a></li>
    36493642                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3650                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    3651                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
     3643                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">5.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.c.13"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.3</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
     3644                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    36523645               </ul>
    36533646            </li>
    36543647            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3655                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.1.2.2</a></li>
     3648                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.2.2</a></li>
    36563649                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    36573650               </ul>
    … …  
    36673660                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    36683661                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    3669                         <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5.1</b></a></li>
     3662                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5</b></a></li>
    36703663                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
    36713664                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
    3672                         <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5.1.1</b></a></li>
    3673                         <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1.1</b></a></li>
    3674                         <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1.1</b></a></li>
    3675                         <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1.1</b></a></li>
    3676                         <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1.1</b></a></li>
    3677                         <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1.1</b></a></li>
    3678                         <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5.1.1</b></a></li>
     3665                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1</b></a></li>
     3666                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.1</b></a></li>
     3667                        <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1</b></a></li>
     3668                        <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1</b></a></li>
     3669                        <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1</b></a></li>
     3670                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1</b></a></li>
     3671                        <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1</b></a></li>
    36793672                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    3680                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>8.1</b></a></li>
    3681                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>8.1</b></a></li>
    3682                         <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>8.2</b></a></li>
     3673                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>8.1</b></a></li>
     3674                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.1</b></a></li>
     3675                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>3.3.2</b></a></li>
    36833676                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    36843677                        <li>CRLF&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>1.2</b></a></li>
    36853678                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
    36863679                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    3687                         <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5.1</b></a></li>
    3688                         <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5.1</b></a></li>
     3680                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5</b></a></li>
     3681                        <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5</b></a></li>
    36893682                        <li>DIGIT&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>1.2</b></a></li>
    36903683                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    … …  
    36943687                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.2</b></a></li>
    36953688                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3696                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>8.3</b></a></li>
     3689                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.2</b></a></li>
    36973690                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    36983691                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>3</b></a></li>
    … …  
    37013694                        <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
    37023695                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7.2</b></a></li>
    3703                         <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1.1</b></a></li>
     3696                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1</b></a></li>
    37043697                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    37053698                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.3</b></a></li>
    … …  
    37103703                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    37113704                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    3712                         <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.2</b></a></li>
    3713                         <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.2</b></a></li>
    3714                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.8</b></a></li>
    3715                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.8</b></a></li>
    3716                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.8</b></a></li>
     3705                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.4</b></a></li>
     3706                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.4</b></a></li>
     3707                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.4</b></a></li>
    37173708                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    3718                         <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.1.1</b></a></li>
     3709                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.1</b></a></li>
    37193710                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    37203711                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.4</b></a></li>
    37213712                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.4</b></a></li>
    3722                         <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.1.1</b></a></li>
     3713                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>5.1</b></a></li>
    37233714                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.4</b></a></li>
    3724                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.3</b></a></li>
     3715                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>5.4.1</b></a></li>
    37253716                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li>
    3726                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.8</b></a></li>
    3727                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>8.8</b></a></li>
     3717                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>8.4</b></a></li>
     3718                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.4</b></a></li>
    37283719                        <li><tt>Request-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1.1</b></a></li>
    37293720                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1.1.2</b></a></li>
    … …  
    37343725                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li>
    37353726                        <li><tt>Status-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.2</b></a></li>
    3736                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>8.4</b></a></li>
     3727                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>5.4</b></a></li>
    37373728                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.4</b></a></li>
    3738                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>8.4</b></a></li>
    3739                         <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>8.4</b></a></li>
    3740                         <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.4</b></a></li>
     3729                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.4</b></a></li>
     3730                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>5.4</b></a></li>
     3731                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>5.4</b></a></li>
    37413732                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
    3742                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.5</b></a></li>
    3743                         <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1.1</b></a></li>
    3744                         <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>5.1</b></a></li>
    3745                         <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.6</b></a></li>
    3746                         <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>5.1</b></a></li>
    3747                         <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5.1</b></a></li>
    3748                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.7</b></a></li>
     3733                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>5.5</b></a></li>
     3734                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.1</b></a></li>
     3735                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5</b></a></li>
     3736                        <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>3.3.1</b></a></li>
     3737                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5</b></a></li>
     3738                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5</b></a></li>
     3739                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>8.3</b></a></li>
    37493740                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37503741                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    3751                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5.1</b></a></li>
     3742                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5</b></a></li>
    37523743                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3753                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>8.8</b></a></li>
     3744                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.4</b></a></li>
    37543745                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.4</b></a></li>
    37553746                     </ul>
    37563747                  </li>
    3757                   <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.70">5.1.2.3</a></li>
     3748                  <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.72">5.2.3</a></li>
    37583749               </ul>
    37593750            </li>
    … …  
    37623753                  <li>Header Fields&nbsp;&nbsp;
    37633754                     <ul>
    3764                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
    3765                         <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    3766                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    3767                         <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    3768                         <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3769                         <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    3770                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3771                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3755                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">5.4</a>, <a href="#rfc.xref.header.connection.5">6.1.2</a>, <a href="#rfc.xref.header.connection.6">6.1.3</a>, <a href="#rfc.xref.header.connection.7">6.1.3.1</a>, <a href="#rfc.xref.header.connection.8">8</a>, <a href="#rfc.iref.h.10"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.9">8.3</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
     3756                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
     3757                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.12"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3758                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5</a>, <a href="#rfc.xref.header.te.2">5.1</a>, <a href="#rfc.iref.h.8"><b>5.4</b></a>, <a href="#rfc.xref.header.te.3">5.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3759                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1</a>, <a href="#rfc.iref.h.9"><b>5.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3760                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">5</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3761                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.13"><b>8.3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3762                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.14"><b>8.4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    37723763                     </ul>
    37733764                  </li>
    37743765                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    37753766                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3776                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3767                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.11"><b>8.2</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    37773768                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    37783769                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38143805            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38153806                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3816                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3807                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.3</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    38173808                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    38183809                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    … …  
    38233814                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a></li>
    38243815                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3825                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">8.7</a></li>
     3816                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">8.3</a></li>
    38263817                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">10.6</a></li>
    38273818                        <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.17">10.6</a></li>
    3828                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3829                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>
     3819                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3820                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>
    38303821                     </ul>
    38313822                  </li>
    3832                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.6</a>, <a href="#Part3"><b>12.1</b></a><ul>
    3833                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">5.1.3</a>, <a href="#rfc.xref.Part3.5">8.6</a></li>
    3834                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">5.3</a></li>
     3823                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">5.3</a>, <a href="#rfc.xref.Part3.4">5.4.1</a>, <a href="#rfc.xref.Part3.5">6.1.3.2</a>, <a href="#Part3"><b>12.1</b></a><ul>
     3824                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">5.3</a></li>
     3825                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">5.4.1</a></li>
    38353826                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    38363827                     </ul>
    … …  
    38543845                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li>
    38553846                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    3856                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
    3857                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.1.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
    3858                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.1.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    3859                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
    3860                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5.1</a></li>
     3847                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
     3848                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
     3849                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
     3850                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
     3851                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5</a></li>
    38613852                     </ul>
    38623853                  </li>
    … …  
    38993890                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    39003891                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    3901                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
    3902                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.3</a>, <a href="#rfc.xref.RFC5226.2">8.7.1</a></li>
     3892                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
     3893                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a></li>
    39033894                     </ul>
    39043895                  </li>
    … …  
    39073898                     </ul>
    39083899                  </li>
    3909                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.8</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
    3910                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.8</a></li>
     3900                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">8.4</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
     3901                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">8.4</a></li>
    39113902                     </ul>
    39123903                  </li>
    … …  
    39223913            </li>
    39233914            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3924                   <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.4"><b>4.3</b></a></li>
    3925                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.1</a>, <a href="#rfc.xref.header.te.2">5.1.1</a>, <a href="#rfc.xref.header.te.3">5.3</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.4</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3915                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.5"><b>4.3</b></a></li>
     3916                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5</a>, <a href="#rfc.xref.header.te.2">5.1</a>, <a href="#rfc.iref.t.6"><b>5.4</b></a>, <a href="#rfc.xref.header.te.3">5.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    39263917                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li>
    3927                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.5</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
    3928                   <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.1</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.6</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3918                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.1</a>, <a href="#rfc.iref.t.7"><b>5.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3919                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">5</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    39293920                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    39303921                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
    … …  
    39333924            </li>
    39343925            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3935                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.7</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3926                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.3</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    39363927                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39373928                  <li>URI scheme&nbsp;&nbsp;
    … …  
    39463937            </li>
    39473938            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3948                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.8</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
     3939                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.4</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    39493940               </ul>
    39503941            </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1537 r1538  
    15591559   The message-body differs from the payload body only when a transfer-coding
    15601560   has been applied, as indicated by the Transfer-Encoding header field
    1561    (<xref target="header.transfer-encoding"/>).  If more than one
     1561   (<xref target="header.transfer-encoding"/>).
     1562</t>
     1563<t>
     1564   The rules for when a message-body is allowed in a message differ for
     1565   requests and responses.
     1566</t>
     1567<t>
     1568   The presence of a message-body in a request is signaled by the
     1569   inclusion of a Content-Length or Transfer-Encoding header field in
     1570   the request's header fields, even if the request method does not
     1571   define any use for a message-body.  This allows the request
     1572   message framing algorithm to be independent of method semantics.
     1573</t>
     1574<t>
     1575   For response messages, whether or not a message-body is included with
     1576   a message is dependent on both the request method and the response
     1577   status code (<xref target="status.code"/>).
     1578   Responses to the HEAD request method never include a message-body
     1579   because the associated response header fields (e.g., Transfer-Encoding,
     1580   Content-Length, etc.) only indicate what their values would have been
     1581   if the request method had been GET.  All 1xx (Informational), 204 (No Content),
     1582   and 304 (Not Modified) responses &MUST-NOT; include a message-body.
     1583   All other responses do include a message-body, although the body
     1584   &MAY; be of zero length.
     1585</t>
     1586
     1587<section title="Transfer-Encoding" anchor="header.transfer-encoding">
     1588  <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>
     1589  <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/>
     1590  <x:anchor-alias value="Transfer-Encoding"/>
     1591<t>
     1592   The "Transfer-Encoding" header field indicates what transfer-codings
     1593   (if any) have been applied to the message body. It differs from
     1594   Content-Encoding (&content-codings;) in that transfer-codings are a property
     1595   of the message (and therefore are removed by intermediaries), whereas
     1596   content-codings are not.
     1597</t>
     1598<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
     1599  <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref>
     1600</artwork></figure>
     1601<t>
     1602   Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:
     1603</t>
     1604<figure><artwork type="example">
     1605  Transfer-Encoding: chunked
     1606</artwork></figure>
     1607<t>
     1608   If multiple encodings have been applied to a representation, the transfer-codings
     1609   &MUST; be listed in the order in which they were applied.
     1610   Additional information about the encoding parameters &MAY; be provided
     1611   by other header fields not defined by this specification.
     1612</t>
     1613<t>
     1614   Many older HTTP/1.0 applications do not understand the Transfer-Encoding
     1615   header field.
     1616</t>
     1617<t>
     1618   If more than one
    15621619   Transfer-Encoding header field is present in a message, the multiple
    15631620   field-values &MUST; be combined into one field-value, according to the
    … …  
    15721629   any implementation along the request/response chain under the constraints
    15731630   found in <xref target="transfer.codings"/>.
     1631</t>
     1632</section>
     1633
     1634<section title="Content-Length" anchor="header.content-length">
     1635  <iref primary="true" item="Content-Length header field" x:for-anchor=""/>
     1636  <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/>
     1637  <x:anchor-alias value="Content-Length"/>
     1638<t>
     1639   The "Content-Length" header field indicates the size of the
     1640   message-body, in decimal number of octets, for any message other than
     1641   a response to a HEAD request or a response with a status code of 304.
     1642   In the case of a response to a HEAD request, Content-Length indicates
     1643   the size of the payload body (not including any potential transfer-coding)
     1644   that would have been sent had the request been a GET.
     1645   In the case of a 304 (Not Modified) response to a GET request,
     1646   Content-Length indicates the size of the payload body (not including
     1647   any potential transfer-coding) that would have been sent in a 200 (OK)
     1648   response.
     1649</t>
     1650<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
     1651  <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>
     1652</artwork></figure>
     1653<t>
     1654   An example is
     1655</t>
     1656<figure><artwork type="example">
     1657  Content-Length: 3495
     1658</artwork></figure>
     1659<t>
     1660   Implementations &SHOULD; use this field to indicate the message-body
     1661   length when no transfer-coding is being applied and the
     1662   payload's body length can be determined prior to being transferred.
     1663   <xref target="message.body"/> describes how recipients determine the length
     1664   of a message-body.
     1665</t>
     1666<t>
     1667   Any Content-Length greater than or equal to zero is a valid value.
     1668</t>
     1669<t>
     1670   Note that the use of this field in HTTP is significantly different from
     1671   the corresponding definition in MIME, where it is an optional field
     1672   used within the "message/external-body" content-type.
    15741673</t>
    15751674<t>
    … …  
    15851684   length.
    15861685</t>
    1587 <t>
    1588    The rules for when a message-body is allowed in a message differ for
    1589    requests and responses.
    1590 </t>
    1591 <t>
    1592    The presence of a message-body in a request is signaled by the
    1593    inclusion of a Content-Length or Transfer-Encoding header field in
    1594    the request's header fields, even if the request method does not
    1595    define any use for a message-body.  This allows the request
    1596    message framing algorithm to be independent of method semantics.
    1597 </t>
    1598 <t>
    1599    For response messages, whether or not a message-body is included with
    1600    a message is dependent on both the request method and the response
    1601    status code (<xref target="status.code"/>).
    1602    Responses to the HEAD request method never include a message-body
    1603    because the associated response header fields (e.g., Transfer-Encoding,
    1604    Content-Length, etc.) only indicate what their values would have been
    1605    if the request method had been GET.  All 1xx (Informational), 204 (No Content),
    1606    and 304 (Not Modified) responses &MUST-NOT; include a message-body.
    1607    All other responses do include a message-body, although the body
    1608    &MAY; be of zero length.
    1609 </t>
     1686</section>
     1687
     1688<section title="Message Body Length" anchor="message.body.length">
    16101689<t>
    16111690   The length of the message-body is determined by one of the following
    … …  
    17171796</t>
    17181797</section>
     1798</section>
    17191799
    17201800<section anchor="incomplete.messages" title="Handling Incomplete Messages">
    … …  
    20512131</section>
    20522132
    2053 
    2054 <section title="Protocol Parameters" anchor="protocol.parameters">
    2055 
    20562133<section title="Transfer Codings" anchor="transfer.codings">
    20572134  <x:anchor-alias value="transfer-coding"/>
    … …  
    23132390</t>
    23142391</section>
    2315 </section>
    2316 
    2317 <section title="Product Tokens" anchor="product.tokens">
    2318   <x:anchor-alias value="product"/>
    2319   <x:anchor-alias value="product-version"/>
    2320 <t>
    2321    Product tokens are used to allow communicating applications to
    2322    identify themselves by software name and version. Most fields using
    2323    product tokens also allow sub-products which form a significant part
    2324    of the application to be listed, separated by whitespace. By
    2325    convention, the products are listed in order of their significance
    2326    for identifying the application.
    2327 </t>
    2328 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
    2329   <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
    2330   <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
     2392
     2393<section title="TE" anchor="header.te">
     2394  <iref primary="true" item="TE header field" x:for-anchor=""/>
     2395  <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/>
     2396  <x:anchor-alias value="TE"/>
     2397  <x:anchor-alias value="t-codings"/>
     2398  <x:anchor-alias value="te-params"/>
     2399  <x:anchor-alias value="te-ext"/>
     2400<t>
     2401   The "TE" header field indicates what extension transfer-codings
     2402   the client is willing to accept in the response, and whether or not it is
     2403   willing to accept trailer fields in a chunked transfer-coding.
     2404</t>
     2405<t>
     2406   Its value consists of the keyword "trailers" and/or a comma-separated
     2407   list of extension transfer-coding names with optional accept
     2408   parameters (as described in <xref target="transfer.codings"/>).
     2409</t>
     2410<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/>
     2411  <x:ref>TE</x:ref>        = #<x:ref>t-codings</x:ref>
     2412  <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] )
     2413  <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> )
     2414  <x:ref>te-ext</x:ref>    = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
    23312415</artwork></figure>
    23322416<t>
    2333    Examples:
     2417   The presence of the keyword "trailers" indicates that the client is
     2418   willing to accept trailer fields in a chunked transfer-coding, as
     2419   defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with
     2420   transfer-coding values even though it does not itself represent a
     2421   transfer-coding.
     2422</t>
     2423<t>
     2424   Examples of its use are:
    23342425</t>
    23352426<figure><artwork type="example">
    2336   User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    2337   Server: Apache/0.8.4
     2427  TE: deflate
     2428  TE:
     2429  TE: trailers, deflate;q=0.5
    23382430</artwork></figure>
    23392431<t>
    2340    Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
    2341    used for advertising or other non-essential information. Although any
    2342    token octet &MAY; appear in a product-version, this token &SHOULD;
    2343    only be used for a version identifier (i.e., successive versions of
    2344    the same product &SHOULD; only differ in the product-version portion of
    2345    the product value).
    2346 </t>
    2347 </section>
     2432   The TE header field only applies to the immediate connection.
     2433   Therefore, the keyword &MUST; be supplied within a Connection header
     2434   field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
     2435</t>
     2436<t>
     2437   A server tests whether a transfer-coding is acceptable, according to
     2438   a TE field, using these rules:
     2439  <list style="numbers">
     2440    <x:lt>
     2441      <t>The "chunked" transfer-coding is always acceptable. If the
     2442         keyword "trailers" is listed, the client indicates that it is
     2443         willing to accept trailer fields in the chunked response on
     2444         behalf of itself and any downstream clients. The implication is
     2445         that, if given, the client is stating that either all
     2446         downstream clients are willing to accept trailer fields in the
     2447         forwarded response, or that it will attempt to buffer the
     2448         response on behalf of downstream recipients.
     2449      </t><t>
     2450         <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a
     2451         chunked response such that a client can be assured of buffering
     2452         the entire response.</t>
     2453    </x:lt>
     2454    <x:lt>
     2455      <t>If the transfer-coding being tested is one of the transfer-codings
     2456         listed in the TE field, then it is acceptable unless it
     2457         is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
     2458         qvalue of 0 means "not acceptable".)</t>
     2459    </x:lt>
     2460    <x:lt>
     2461      <t>If multiple transfer-codings are acceptable, then the
     2462         acceptable transfer-coding with the highest non-zero qvalue is
     2463         preferred.  The "chunked" transfer-coding always has a qvalue
     2464         of 1.</t>
     2465    </x:lt>
     2466  </list>
     2467</t>
     2468<t>
     2469   If the TE field-value is empty or if no TE field is present, the only
     2470   acceptable transfer-coding is "chunked". A message with no transfer-coding is
     2471   always acceptable.
     2472</t>
    23482473
    23492474<section title="Quality Values" anchor="quality.values">
    … …  
    23722497</x:note>
    23732498</section>
    2374 
     2499</section>
     2500
     2501<section title="Trailer" anchor="header.trailer">
     2502  <iref primary="true" item="Trailer header field" x:for-anchor=""/>
     2503  <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>
     2504  <x:anchor-alias value="Trailer"/>
     2505<t>
     2506   The "Trailer" header field indicates that the given set of
     2507   header fields is present in the trailer of a message encoded with
     2508   chunked transfer-coding.
     2509</t>
     2510<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>
     2511  <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
     2512</artwork></figure>
     2513<t>
     2514   An HTTP/1.1 message &SHOULD; include a Trailer header field in a
     2515   message using chunked transfer-coding with a non-empty trailer. Doing
     2516   so allows the recipient to know which header fields to expect in the
     2517   trailer.
     2518</t>
     2519<t>
     2520   If no Trailer header field is present, the trailer &SHOULD-NOT;  include
     2521   any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of
     2522   trailer fields in a "chunked" transfer-coding.
     2523</t>
     2524<t>
     2525   Message header fields listed in the Trailer header field &MUST-NOT;
     2526   include the following header fields:
     2527  <list style="symbols">
     2528    <t>Transfer-Encoding</t>
     2529    <t>Content-Length</t>
     2530    <t>Trailer</t>
     2531  </list>
     2532</t>
     2533</section>
    23752534</section>
    23762535
    … …  
    29983157</section>
    29993158
    3000 <section title="Content-Length" anchor="header.content-length">
    3001   <iref primary="true" item="Content-Length header field" x:for-anchor=""/>
    3002   <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/>
    3003   <x:anchor-alias value="Content-Length"/>
    3004 <t>
    3005    The "Content-Length" header field indicates the size of the
    3006    message-body, in decimal number of octets, for any message other than
    3007    a response to a HEAD request or a response with a status code of 304.
    3008    In the case of a response to a HEAD request, Content-Length indicates
    3009    the size of the payload body (not including any potential transfer-coding)
    3010    that would have been sent had the request been a GET.
    3011    In the case of a 304 (Not Modified) response to a GET request,
    3012    Content-Length indicates the size of the payload body (not including
    3013    any potential transfer-coding) that would have been sent in a 200 (OK)
    3014    response.
    3015 </t>
    3016 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
    3017   <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>
    3018 </artwork></figure>
    3019 <t>
    3020    An example is
    3021 </t>
    3022 <figure><artwork type="example">
    3023   Content-Length: 3495
    3024 </artwork></figure>
    3025 <t>
    3026    Implementations &SHOULD; use this field to indicate the message-body
    3027    length when no transfer-coding is being applied and the
    3028    payload's body length can be determined prior to being transferred.
    3029    <xref target="message.body"/> describes how recipients determine the length
    3030    of a message-body.
    3031 </t>
    3032 <t>
    3033    Any Content-Length greater than or equal to zero is a valid value.
    3034 </t>
    3035 <t>
    3036    Note that the use of this field in HTTP is significantly different from
    3037    the corresponding definition in MIME, where it is an optional field
    3038    used within the "message/external-body" content-type.
    3039 </t>
    3040 </section>
    3041 
    30423159<section title="Host" anchor="header.host">
    30433160  <iref primary="true" item="Host header field" x:for-anchor=""/>
    … …  
    31093226</section>
    31103227
    3111 <section title="TE" anchor="header.te">
    3112   <iref primary="true" item="TE header field" x:for-anchor=""/>
    3113   <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/>
    3114   <x:anchor-alias value="TE"/>
    3115   <x:anchor-alias value="t-codings"/>
    3116   <x:anchor-alias value="te-params"/>
    3117   <x:anchor-alias value="te-ext"/>
    3118 <t>
    3119    The "TE" header field indicates what extension transfer-codings
    3120    the client is willing to accept in the response, and whether or not it is
    3121    willing to accept trailer fields in a chunked transfer-coding.
    3122 </t>
    3123 <t>
    3124    Its value consists of the keyword "trailers" and/or a comma-separated
    3125    list of extension transfer-coding names with optional accept
    3126    parameters (as described in <xref target="transfer.codings"/>).
    3127 </t>
    3128 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/>
    3129   <x:ref>TE</x:ref>        = #<x:ref>t-codings</x:ref>
    3130   <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] )
    3131   <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> )
    3132   <x:ref>te-ext</x:ref>    = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
    3133 </artwork></figure>
    3134 <t>
    3135    The presence of the keyword "trailers" indicates that the client is
    3136    willing to accept trailer fields in a chunked transfer-coding, as
    3137    defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with
    3138    transfer-coding values even though it does not itself represent a
    3139    transfer-coding.
    3140 </t>
    3141 <t>
    3142    Examples of its use are:
    3143 </t>
    3144 <figure><artwork type="example">
    3145   TE: deflate
    3146   TE:
    3147   TE: trailers, deflate;q=0.5
    3148 </artwork></figure>
    3149 <t>
    3150    The TE header field only applies to the immediate connection.
    3151    Therefore, the keyword &MUST; be supplied within a Connection header
    3152    field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
    3153 </t>
    3154 <t>
    3155    A server tests whether a transfer-coding is acceptable, according to
    3156    a TE field, using these rules:
    3157   <list style="numbers">
    3158     <x:lt>
    3159       <t>The "chunked" transfer-coding is always acceptable. If the
    3160          keyword "trailers" is listed, the client indicates that it is
    3161          willing to accept trailer fields in the chunked response on
    3162          behalf of itself and any downstream clients. The implication is
    3163          that, if given, the client is stating that either all
    3164          downstream clients are willing to accept trailer fields in the
    3165          forwarded response, or that it will attempt to buffer the
    3166          response on behalf of downstream recipients.
    3167       </t><t>
    3168          <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a
    3169          chunked response such that a client can be assured of buffering
    3170          the entire response.</t>
    3171     </x:lt>
    3172     <x:lt>
    3173       <t>If the transfer-coding being tested is one of the transfer-codings
    3174          listed in the TE field, then it is acceptable unless it
    3175          is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
    3176          qvalue of 0 means "not acceptable".)</t>
    3177     </x:lt>
    3178     <x:lt>
    3179       <t>If multiple transfer-codings are acceptable, then the
    3180          acceptable transfer-coding with the highest non-zero qvalue is
    3181          preferred.  The "chunked" transfer-coding always has a qvalue
    3182          of 1.</t>
    3183     </x:lt>
    3184   </list>
    3185 </t>
    3186 <t>
    3187    If the TE field-value is empty or if no TE field is present, the only
    3188    acceptable transfer-coding is "chunked". A message with no transfer-coding is
    3189    always acceptable.
    3190 </t>
    3191 </section>
    3192 
    3193 <section title="Trailer" anchor="header.trailer">
    3194   <iref primary="true" item="Trailer header field" x:for-anchor=""/>
    3195   <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>
    3196   <x:anchor-alias value="Trailer"/>
    3197 <t>
    3198    The "Trailer" header field indicates that the given set of
    3199    header fields is present in the trailer of a message encoded with
    3200    chunked transfer-coding.
    3201 </t>
    3202 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>
    3203   <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
    3204 </artwork></figure>
    3205 <t>
    3206    An HTTP/1.1 message &SHOULD; include a Trailer header field in a
    3207    message using chunked transfer-coding with a non-empty trailer. Doing
    3208    so allows the recipient to know which header fields to expect in the
    3209    trailer.
    3210 </t>
    3211 <t>
    3212    If no Trailer header field is present, the trailer &SHOULD-NOT;  include
    3213    any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of
    3214    trailer fields in a "chunked" transfer-coding.
    3215 </t>
    3216 <t>
    3217    Message header fields listed in the Trailer header field &MUST-NOT;
    3218    include the following header fields:
    3219   <list style="symbols">
    3220     <t>Transfer-Encoding</t>
    3221     <t>Content-Length</t>
    3222     <t>Trailer</t>
    3223   </list>
    3224 </t>
    3225 </section>
    3226 
    3227 <section title="Transfer-Encoding" anchor="header.transfer-encoding">
    3228   <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>
    3229   <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/>
    3230   <x:anchor-alias value="Transfer-Encoding"/>
    3231 <t>
    3232    The "Transfer-Encoding" header field indicates what transfer-codings
    3233    (if any) have been applied to the message body. It differs from
    3234    Content-Encoding (&content-codings;) in that transfer-codings are a property
    3235    of the message (and therefore are removed by intermediaries), whereas
    3236    content-codings are not.
    3237 </t>
    3238 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
    3239   <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref>
    3240 </artwork></figure>
    3241 <t>
    3242    Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:
    3243 </t>
    3244 <figure><artwork type="example">
    3245   Transfer-Encoding: chunked
    3246 </artwork></figure>
    3247 <t>
    3248    If multiple encodings have been applied to a representation, the transfer-codings
    3249    &MUST; be listed in the order in which they were applied.
    3250    Additional information about the encoding parameters &MAY; be provided
    3251    by other header fields not defined by this specification.
    3252 </t>
    3253 <t>
    3254    Many older HTTP/1.0 applications do not understand the Transfer-Encoding
    3255    header field.
    3256 </t>
    3257 </section>
    3258 
    32593228<section title="Upgrade" anchor="header.upgrade">
    32603229  <iref primary="true" item="Upgrade header field" x:for-anchor=""/>
    32613230  <iref primary="true" item="Header Fields" subitem="Upgrade" x:for-anchor=""/>
    32623231  <x:anchor-alias value="Upgrade"/>
     3232  <x:anchor-alias value="protocol"/>
     3233  <x:anchor-alias value="protocol-name"/>
     3234  <x:anchor-alias value="protocol-version"/>
    32633235<t>
    32643236   The "Upgrade" header field allows the client to specify what
    … …  
    32683240</t>
    32693241<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/>
    3270   <x:ref>Upgrade</x:ref> = 1#<x:ref>product</x:ref>
     3242  <x:ref>Upgrade</x:ref>  = 1#<x:ref>protocol</x:ref>
     3243
     3244  <x:ref>protocol</x:ref> = <x:ref>protocol-name</x:ref> ["/" <x:ref>protocol-version</x:ref>]
     3245  <x:ref>protocol-name</x:ref>     = <x:ref>token</x:ref>
     3246  <x:ref>protocol-version</x:ref>  = <x:ref>token</x:ref>
    32713247</artwork></figure>
    32723248<t>
    … …  
    33283304<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
    33293305<t>
    3330    The HTTP Upgrade Token Registry defines the name space for product
     3306   The HTTP Upgrade Token Registry defines the name space for protocol-name
    33313307   tokens used to identify protocols in the Upgrade header field.
    3332    Each registered token is associated with contact information and
     3308   Each registered protocol-name is associated with contact information and
    33333309   an optional set of specifications that details how the connection
    33343310   will be processed after it has been upgraded.
    … …  
    33403316   Registrations are subject to the following rules:
    33413317  <list style="numbers">
    3342     <t>A token, once registered, stays registered forever.</t>
     3318    <t>A protocol-name token, once registered, stays registered forever.</t>
    33433319    <t>The registration &MUST; name a responsible party for the
    33443320       registration.</t>
    33453321    <t>The registration &MUST; name a point of contact.</t>
    3346     <t>The registration &MAY; name a set of specifications associated with that
    3347        token. Such specifications need not be publicly available.</t>
     3322    <t>The registration &MAY; name a set of specifications associated with
     3323       that token. Such specifications need not be publicly available.</t>
     3324    <t>The registration &SHOULD; name a set of expected "protocol-version"
     3325       tokens associated with that token at the time of registration.</t>
    33483326    <t>The responsible party &MAY; change the registration at any time.
    33493327       The IANA will keep a record of all such changes, and make them
    33503328       available upon request.</t>
    3351     <t>The responsible party for the first registration of a "product"
    3352        token &MUST; approve later registrations of a "version" token
    3353        together with that "product" token before they can be registered.</t>
    3354     <t>If absolutely required, the IESG &MAY; reassign the responsibility
    3355        for a token. This will normally only be used in the case when a
     3329    <t>The IESG &MAY; reassign responsibility for a protocol token.
     3330       This will normally only be used in the case when a
    33563331       responsible party cannot be contacted.</t>
    33573332  </list>
    … …  
    33653340  <iref primary="true" item="Via header field" x:for-anchor=""/>
    33663341  <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
    3367   <x:anchor-alias value="protocol-name"/>
    3368   <x:anchor-alias value="protocol-version"/>
    33693342  <x:anchor-alias value="pseudonym"/>
    33703343  <x:anchor-alias value="received-by"/>
    … …  
    33853358                          [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
    33863359  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
    3387   <x:ref>protocol-name</x:ref>     = <x:ref>token</x:ref>
    3388   <x:ref>protocol-version</x:ref>  = <x:ref>token</x:ref>
    33893360  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    33903361  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
    … …  
    50825053
    50835054<x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in [RFC3986], Section 4.1&gt;
    5084 <x:ref>Upgrade</x:ref> = *( "," OWS ) product *( OWS "," [ OWS product ] )
     5055<x:ref>Upgrade</x:ref> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
    50855056
    50865057<x:ref>Via</x:ref> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
    … …  
    51245095<x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in [RFC3986], Section 3.3&gt;
    51255096<x:ref>port</x:ref> = &lt;port, defined in [RFC3986], Section 3.2.3&gt;
    5126 <x:ref>product</x:ref> = token [ "/" product-version ]
    5127 <x:ref>product-version</x:ref> = token
     5097<x:ref>protocol</x:ref> = protocol-name [ "/" protocol-version ]
    51285098<x:ref>protocol-name</x:ref> = token
    51295099<x:ref>protocol-version</x:ref> = token

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1536 r1538  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 19, 2012";
     462       content: "Expires August 21, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    490490      <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7">
    491491      <link rel="Chapter" title="8 Date/Time Formats" href="#rfc.section.8">
    492       <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9">
    493       <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10">
    494       <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11">
    495       <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12">
    496       <link rel="Chapter" href="#rfc.section.13" title="13 References">
     492      <link rel="Chapter" title="9 Product Tokens" href="#rfc.section.9">
     493      <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10">
     494      <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11">
     495      <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12">
     496      <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13">
     497      <link rel="Chapter" href="#rfc.section.14" title="14 References">
    497498      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    498499      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    … …  
    512513      <meta name="dct.creator" content="Reschke, J. F.">
    513514      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    514       <meta name="dct.issued" scheme="ISO8601" content="2012-02-16">
     515      <meta name="dct.issued" scheme="ISO8601" content="2012-02-18">
    515516      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    516517      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    543544            </tr>
    544545            <tr>
    545                <td class="left">Expires: August 19, 2012</td>
     546               <td class="left">Expires: August 21, 2012</td>
    546547               <td class="right">HP</td>
    547548            </tr>
    … …  
    596597            <tr>
    597598               <td class="left"></td>
    598                <td class="right">February 16, 2012</td>
     599               <td class="right">February 18, 2012</td>
    599600            </tr>
    600601         </tbody>
    … …  
    626627         in progress”.
    627628      </p>
    628       <p>This Internet-Draft will expire on August 19, 2012.</p>
     629      <p>This Internet-Draft will expire on August 21, 2012.</p>
    629630      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    630631      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    753754         </li>
    754755         <li>8.&nbsp;&nbsp;&nbsp;<a href="#http.date">Date/Time Formats</a></li>
    755          <li>9.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    756                <li>9.1&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li>
    757                <li>9.2&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
    758                <li>9.3&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
    759                <li>9.4&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li>
    760                <li>9.5&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
    761                <li>9.6&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
    762                <li>9.7&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li>
    763                <li>9.8&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
    764                <li>9.9&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li>
    765                <li>9.10&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li>
     756         <li>9.&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
     757         <li>10.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
     758               <li>10.1&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li>
     759               <li>10.2&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
     760               <li>10.3&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
     761               <li>10.4&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li>
     762               <li>10.5&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
     763               <li>10.6&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
     764               <li>10.7&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li>
     765               <li>10.8&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
     766               <li>10.9&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li>
     767               <li>10.10&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li>
    766768            </ul>
    767769         </li>
    768          <li>10.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    769                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
    770                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
    771                <li>10.3&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     770         <li>11.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     771               <li>11.1&nbsp;&nbsp;&nbsp;<a href="#method.registration">Method Registry</a></li>
     772               <li>11.2&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registry</a></li>
     773               <li>11.3&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    772774            </ul>
    773775         </li>
    774          <li>11.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    775                <li>11.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
    776                <li>11.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    777                <li>11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
    778                <li>11.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li>
     776         <li>12.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     777               <li>12.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
     778               <li>12.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
     779               <li>12.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
     780               <li>12.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.12.4">Security Considerations for CONNECT</a></li>
    779781            </ul>
    780782         </li>
    781          <li>12.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    782          <li>13.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    783                <li>13.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    784                <li>13.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     783         <li>13.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     784         <li>14.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     785               <li>14.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     786               <li>14.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    785787            </ul>
    786788         </li>
    … …  
    864866  <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    865867  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><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.7</a>&gt;
    866   <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>&gt;
    867   <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     868  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><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.7</a>&gt;
    868869</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    869       <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     870      <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<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>). The method is case-sensitive.
    870871      </p>
    871872      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#core.rules" class="smpl">token</a>
    872 </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
     873</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;10.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
    873874         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
    874875         resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
    … …  
    946947         to a single application, so that this is clear.
    947948      </p>
    948       <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.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>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
     949      <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
    949950         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    950951         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    955956      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    956957      <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource,
    957          or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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> for a general definition of their syntax.
     958         or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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> for a general definition of their syntax.
    958959      </p>
    959960      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2>
    … …  
    963964         with "X-" if they are to be registered (either immediately or in the future).
    964965      </p>
    965       <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     966      <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    966967         can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    967968      </p>
    968969      <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    969970         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    970          quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</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>).
     971         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.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>).
    971972      </p>
    972973      <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
    … …  
    986987      <ul>
    987988         <li>
    988             <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>).
     989            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>).
    989990            </p>
    990991            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    10021003         </li>
    10031004         <li>
    1004             <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</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>).
     1005            <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 9.1</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>).
    10051006            </p>
    10061007         </li>
    … …  
    10131014         </li>
    10141015         <li>
    1015             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1016            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</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>).
    10161017            </p>
    10171018         </li>
    … …  
    10561057               <tr>
    10571058                  <td class="left">Expect</td>
    1058                   <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.3</a></td>
     1059                  <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;10.3</a></td>
    10591060               </tr>
    10601061               <tr>
    10611062                  <td class="left">From</td>
    1062                   <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;9.4</a></td>
     1063                  <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;10.4</a></td>
    10631064               </tr>
    10641065               <tr>
    10651066                  <td class="left">Host</td>
    1066                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1067                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    10671068               </tr>
    10681069               <tr>
    … …  
    10881089               <tr>
    10891090                  <td class="left">Max-Forwards</td>
    1090                   <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.6</a></td>
     1091                  <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;10.6</a></td>
    10911092               </tr>
    10921093               <tr>
    … …  
    11001101               <tr>
    11011102                  <td class="left">Referer</td>
    1102                   <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;9.7</a></td>
     1103                  <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;10.7</a></td>
    11031104               </tr>
    11041105               <tr>
    11051106                  <td class="left">TE</td>
    1106                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1107                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    11071108               </tr>
    11081109               <tr>
    11091110                  <td class="left">User-Agent</td>
    1110                   <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;9.10</a></td>
     1111                  <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;10.10</a></td>
    11111112               </tr>
    11121113            </tbody>
    … …  
    11151116      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    11161117      <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    1117          Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1118         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    11181119      </p>
    11191120      <div id="rfc.table.u.3">
    … …  
    11361137               <tr>
    11371138                  <td class="left">Allow</td>
    1138                   <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section&nbsp;9.1</a></td>
     1139                  <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section&nbsp;10.1</a></td>
    11391140               </tr>
    11401141               <tr>
    11411142                  <td class="left">Date</td>
    1142                   <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;9.2</a></td>
     1143                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;10.2</a></td>
    11431144               </tr>
    11441145               <tr>
    … …  
    11481149               <tr>
    11491150                  <td class="left">Location</td>
    1150                   <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.5</a></td>
     1151                  <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;10.5</a></td>
    11511152               </tr>
    11521153               <tr>
    … …  
    11561157               <tr>
    11571158                  <td class="left">Retry-After</td>
    1158                   <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;9.8</a></td>
     1159                  <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;10.8</a></td>
    11591160               </tr>
    11601161               <tr>
    11611162                  <td class="left">Server</td>
    1162                   <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section&nbsp;9.9</a></td>
     1163                  <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section&nbsp;10.9</a></td>
    11631164               </tr>
    11641165               <tr>
    … …  
    14371438         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    14381439      </p>
    1439       <p id="rfc.section.5.p.2">A representation 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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
     1440      <p id="rfc.section.5.p.2">A representation 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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
    14401441         to ensure safe and proper transfer of the message.
    14411442      </p>
    … …  
    14431444      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    14441445      <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    1445       <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (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.28"><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
     1446      <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (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.27"><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
    14461447         rules are used (with the first applicable one being selected):
    14471448      </p>
    … …  
    15131514         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
    15141515      </p>
    1515       <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     1516      <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;10.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
    15161517      </p>
    15171518      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="GET" href="#GET">GET</a></h2>
    … …  
    15371538      <p id="rfc.section.6.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    15381539      </p>
    1539       <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations when used for forms.
     1540      <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;12.2</a> for security considerations when used for forms.
    15401541      </p>
    15411542      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h2>
    … …  
    15731574      </p>
    15741575      <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
    1575          a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.5</a>).
     1576         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;10.5</a>).
    15761577      </p>
    15771578      <p id="rfc.section.6.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 field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</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>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    … …  
    16631664      <div id="rfc.iref.m.7"></div>
    16641665      <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
    1665          the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;9.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
     1666         the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
    16661667      </p>
    16671668      <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1668          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1669         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    16691670         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    16701671         infinite loop.
    16711672      </p>
    1672       <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1673      <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    16731674      </p>
    16741675      <div id="rfc.iref.c.1"></div>
    … …  
    16781679         forwarding of packets until the connection is closed.
    16791680      </p>
    1680       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1681      <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    16811682         For example,
    16821683      </p>
    … …  
    17451746      <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    17461747         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1747          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1748         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    17481749      </p>
    17491750      <div id="rfc.iref.23"></div>
    17501751      <div id="rfc.iref.s.3"></div>
    17511752      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1752       <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1753      <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    17531754         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    17541755      </p>
    … …  
    18031804      <div id="rfc.iref.s.7"></div>
    18041805      <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1805       <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1806      <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    18061807      </p>
    18071808      <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code
    … …  
    18381839         another input action.
    18391840      </p>
    1840       <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1841      <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    18411842      </p>
    18421843      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    18761877         </p>
    18771878      </div>
    1878       <p id="rfc.section.7.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;9.5</a>.
     1879      <p id="rfc.section.7.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;10.5</a>.
    18791880      </p>
    18801881      <p id="rfc.section.7.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
    … …  
    20922093      <div id="rfc.iref.s.30"></div>
    20932094      <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    2094       <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     2095      <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;10.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    20952096         not be met by the next-hop server.
    20962097      </p>
    … …  
    20982099      <div id="rfc.iref.s.31"></div>
    20992100      <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2100       <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
     2101      <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
    21012102      </p>
    21022103      <div id="rfc.figure.u.8"></div>
    … …  
    21372138      <p id="rfc.section.7.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p>
    21382139      <p id="rfc.section.7.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
    2139          delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     2140         delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;10.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
    21402141      </p>
    21412142      <div class="note" id="rfc.section.7.5.4.p.3">
    … …  
    21592160      <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    21602161         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2161          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     2162         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    21622163      </p>
    21632164      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h1>
    … …  
    22472248         </p>
    22482249      </div>
    2249       <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>
    2250       <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>
     2250      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h1>
     2251      <p id="rfc.section.9.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
     2252         using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace.
     2253         By convention, the products are listed in order of their significance for identifying the application.
     2254      </p>
     2255      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#core.rules" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
     2256  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a>
     2257</pre><p id="rfc.section.9.p.3">Examples:</p>
     2258      <div id="rfc.figure.u.17"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     2259  Server: Apache/0.8.4
     2260</pre><p id="rfc.section.9.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
     2261      </p>
     2262      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     2263      <p id="rfc.section.10.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
    22512264      <div id="rfc.iref.a.1"></div>
    22522265      <div id="rfc.iref.h.2"></div>
    2253       <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>
    2254       <p id="rfc.section.9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
     2266      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
     2267      <p id="rfc.section.10.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
    22552268         is strictly to inform the recipient of valid request methods associated with the resource.
    22562269      </p>
    2257       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a>
    2258 </pre><p id="rfc.section.9.1.p.3">Example of use:</p>
    2259       <div id="rfc.figure.u.17"></div><pre class="text">  Allow: GET, HEAD, PUT
    2260 </pre><p id="rfc.section.9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    2261       <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
     2270      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a>
     2271</pre><p id="rfc.section.10.1.p.3">Example of use:</p>
     2272      <div id="rfc.figure.u.19"></div><pre class="text">  Allow: GET, HEAD, PUT
     2273</pre><p id="rfc.section.10.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
     2274      <p id="rfc.section.10.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
    22622275         to the generic message handling rules.
    22632276      </p>
    22642277      <div id="rfc.iref.d.2"></div>
    22652278      <div id="rfc.iref.h.3"></div>
    2266       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    2267       <p id="rfc.section.9.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
     2279      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
     2280      <p id="rfc.section.10.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
    22682281         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;8</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    22692282      </p>
    2270       <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
    2271 </pre><p id="rfc.section.9.2.p.3">An example is</p>
    2272       <div id="rfc.figure.u.19"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2273 </pre><p id="rfc.section.9.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
     2283      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
     2284</pre><p id="rfc.section.10.2.p.3">An example is</p>
     2285      <div id="rfc.figure.u.21"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
     2286</pre><p id="rfc.section.10.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    22742287      </p>
    22752288      <ol>
    … …  
    22822295         </li>
    22832296      </ol>
    2284       <p id="rfc.section.9.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2285       </p>
    2286       <p id="rfc.section.9.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
     2297      <p id="rfc.section.10.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
     2298      </p>
     2299      <p id="rfc.section.10.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    22872300         when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
    22882301      </p>
    2289       <p id="rfc.section.9.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
     2302      <p id="rfc.section.10.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    22902303         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    22912304         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    … …  
    22942307      <div id="rfc.iref.e.1"></div>
    22952308      <div id="rfc.iref.h.4"></div>
    2296       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    2297       <p id="rfc.section.9.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
    2298       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
     2309      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
     2310      <p id="rfc.section.10.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
     2311      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
    22992312 
    23002313  <a href="#header.expect" class="smpl">expectation</a>  = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ]
    … …  
    23042317  <a href="#header.expect" class="smpl">expect-name</a>  = <a href="#core.rules" class="smpl">token</a>
    23052318  <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a>
    2306 </pre><p id="rfc.section.9.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
     2319</pre><p id="rfc.section.10.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
    23072320         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
    23082321      </p>
    2309       <p id="rfc.section.9.3.p.4">The only expectation defined by this specification is:</p>
    2310       <p id="rfc.section.9.3.p.5"><span id="rfc.iref.87"></span><span id="rfc.iref.e.2"></span> 100-continue
     2322      <p id="rfc.section.10.3.p.4">The only expectation defined by this specification is:</p>
     2323      <p id="rfc.section.10.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue
    23112324      </p>
    23122325      <ul class="empty">
    2313          <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.
     2326         <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.
    23142327         </li>
    23152328      </ul>
    2316       <p id="rfc.section.9.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>
    2317       <p id="rfc.section.9.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header
     2329      <p id="rfc.section.10.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>
     2330      <p id="rfc.section.10.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header
    23182331         field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    23192332      </p>
    2320       <p id="rfc.section.9.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
     2333      <p id="rfc.section.10.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    23212334      <div id="rfc.iref.f.1"></div>
    23222335      <div id="rfc.iref.h.5"></div>
    2323       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
    2324       <p id="rfc.section.9.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    2325       </p>
    2326       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
     2336      <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
     2337      <p id="rfc.section.10.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:
     2338      </p>
     2339      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
    23272340 
    23282341  <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt;
    2329 </pre><p id="rfc.section.9.4.p.3">An example is:</p>
    2330       <div id="rfc.figure.u.22"></div><pre class="text">  From: webmaster@example.org
    2331 </pre><p id="rfc.section.9.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
     2342</pre><p id="rfc.section.10.4.p.3">An example is:</p>
     2343      <div id="rfc.figure.u.24"></div><pre class="text">  From: webmaster@example.org
     2344</pre><p id="rfc.section.10.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    23322345         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
    23332346         end.
    23342347      </p>
    2335       <p id="rfc.section.9.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original
     2348      <p id="rfc.section.10.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original
    23362349         issuer's address <em class="bcp14">SHOULD</em> be used.
    23372350      </p>
    2338       <p id="rfc.section.9.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's
     2351      <p id="rfc.section.10.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's
    23392352         security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at
    23402353         any time prior to a request.
    … …  
    23422355      <div id="rfc.iref.l.1"></div>
    23432356      <div id="rfc.iref.h.6"></div>
    2344       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    2345       <p id="rfc.section.9.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
    2346       </p>
    2347       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    2348 </pre><p id="rfc.section.9.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
     2357      <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
     2358      <p id="rfc.section.10.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
     2359      </p>
     2360      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
     2361</pre><p id="rfc.section.10.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
    23492362         the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
    23502363      </p>
    2351       <p id="rfc.section.9.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
     2364      <p id="rfc.section.10.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
    23522365         then the original URI's fragment identifier is added to the final value.
    23532366      </p>
    2354       <div id="rfc.figure.u.24"></div>
     2367      <div id="rfc.figure.u.26"></div>
    23552368      <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p>  <pre class="text">  Location: /pub/WWW/People.html#tim
    23562369</pre>  <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p>
    2357       <div id="rfc.figure.u.25"></div>
     2370      <div id="rfc.figure.u.27"></div>
    23582371      <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p>  <pre class="text">  Location: http://www.example.net/index.html
    23592372</pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p>
    2360       <div class="note" id="rfc.section.9.5.p.7">
     2373      <div class="note" id="rfc.section.10.5.p.7">
    23612374         <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
    23622375            or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section&nbsp;1.1</a>).
    23632376         </p>
    23642377      </div>
    2365       <p id="rfc.section.9.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
     2378      <p id="rfc.section.10.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
    23662379         in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
    23672380      </p>
    2368       <div class="note" id="rfc.section.9.5.p.9">
     2381      <div class="note" id="rfc.section.10.5.p.9">
    23692382         <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.13"><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.
    23702383            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    … …  
    23732386      <div id="rfc.iref.m.9"></div>
    23742387      <div id="rfc.iref.h.7"></div>
    2375       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    2376       <p id="rfc.section.9.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
     2388      <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
     2389      <p id="rfc.section.10.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
    23772390         to trace a request which appears to be failing or looping mid-chain.
    23782391      </p>
    2379       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    2380 </pre><p id="rfc.section.9.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    2381       <p id="rfc.section.9.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    2382       </p>
    2383       <p id="rfc.section.9.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
     2392      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
     2393</pre><p id="rfc.section.10.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
     2394      <p id="rfc.section.10.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
     2395      </p>
     2396      <p id="rfc.section.10.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
    23842397      </p>
    23852398      <div id="rfc.iref.r.1"></div>
    23862399      <div id="rfc.iref.h.8"></div>
    2387       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    2388       <p id="rfc.section.9.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI
     2400      <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
     2401      <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI
    23892402         was obtained (the "referrer", although the header field is misspelled.).
    23902403      </p>
    2391       <p id="rfc.section.9.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
     2404      <p id="rfc.section.10.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
    23922405         etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
    23932406         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    23942407      </p>
    2395       <p id="rfc.section.9.7.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),
     2408      <p id="rfc.section.10.7.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),
    23962409         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
    23972410         non-HTTP URIs (e.g., FTP).
    23982411      </p>
    2399       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    2400 </pre><p id="rfc.section.9.7.p.5">Example:</p>
    2401       <div id="rfc.figure.u.28"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    2402 </pre><p id="rfc.section.9.7.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.
     2412      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
     2413</pre><p id="rfc.section.10.7.p.5">Example:</p>
     2414      <div id="rfc.figure.u.30"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
     2415</pre><p id="rfc.section.10.7.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;12.2</a> for security considerations.
    24032416      </p>
    24042417      <div id="rfc.iref.r.2"></div>
    24052418      <div id="rfc.iref.h.9"></div>
    2406       <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
    2407       <p id="rfc.section.9.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
     2419      <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
     2420      <p id="rfc.section.10.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
    24082421         to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing
    24092422         the redirected request.
    24102423      </p>
    2411       <p id="rfc.section.9.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
    2412       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
     2424      <p id="rfc.section.10.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
     2425      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    24132426</pre><div id="rule.delta-seconds">
    2414          <p id="rfc.section.9.8.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
     2427         <p id="rfc.section.10.8.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
    24152428      </div>
    2416       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    2417 </pre><p id="rfc.section.9.8.p.6">Two examples of its use are</p>
    2418       <div id="rfc.figure.u.31"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
     2429      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     2430</pre><p id="rfc.section.10.8.p.6">Two examples of its use are</p>
     2431      <div id="rfc.figure.u.33"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    24192432  Retry-After: 120
    2420 </pre><p id="rfc.section.9.8.p.8">In the latter example, the delay is 2 minutes.</p>
     2433</pre><p id="rfc.section.10.8.p.8">In the latter example, the delay is 2 minutes.</p>
    24212434      <div id="rfc.iref.s.38"></div>
    24222435      <div id="rfc.iref.h.10"></div>
    2423       <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    2424       <p id="rfc.section.9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2425       <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2436      <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
     2437      <p id="rfc.section.10.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
     2438      <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    24262439         identifying the application.
    24272440      </p>
    2428       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    2429 </pre><p id="rfc.section.9.9.p.4">Example:</p>
    2430       <div id="rfc.figure.u.33"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2431 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    2432       </p>
    2433       <div class="note" id="rfc.section.9.9.p.7">
     2441      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.37"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
     2442</pre><p id="rfc.section.10.9.p.4">Example:</p>
     2443      <div id="rfc.figure.u.35"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
     2444</pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2445      </p>
     2446      <div class="note" id="rfc.section.10.9.p.7">
    24342447         <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    24352448            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    … …  
    24392452      <div id="rfc.iref.u.1"></div>
    24402453      <div id="rfc.iref.h.11"></div>
    2441       <h2 id="rfc.section.9.10"><a href="#rfc.section.9.10">9.10</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
    2442       <p id="rfc.section.9.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
    2443       </p>
    2444       <p id="rfc.section.9.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
     2454      <h2 id="rfc.section.10.10"><a href="#rfc.section.10.10">10.10</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
     2455      <p id="rfc.section.10.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
     2456      </p>
     2457      <p id="rfc.section.10.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
    24452458         user agent limitations.
    24462459      </p>
    2447       <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2460      <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    24482461         for identifying the application.
    24492462      </p>
    2450       <p id="rfc.section.9.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly
     2463      <p id="rfc.section.10.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly
    24512464         fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed
    24522465         User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes.
    24532466      </p>
    2454       <p id="rfc.section.9.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility
     2467      <p id="rfc.section.10.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility
    24552468         with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products;
    24562469         doing so makes the field value more difficult to parse.
    24572470      </p>
    2458       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    2459 </pre><p id="rfc.section.9.10.p.7">Example:</p>
    2460       <div id="rfc.figure.u.35"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    2461 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    2462       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
    2463       <p id="rfc.section.10.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
    2464       </p>
    2465       <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
     2471      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.38"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
     2472</pre><p id="rfc.section.10.10.p.7">Example:</p>
     2473      <div id="rfc.figure.u.37"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     2474</pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     2475      <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
     2476      <p id="rfc.section.11.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a> of this document.
     2477      </p>
     2478      <p id="rfc.section.11.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
    24662479      </p>
    24672480      <div id="rfc.table.1">
    … …  
    25272540         </table>
    25282541      </div>
    2529       <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
    2530       <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a> of this document.
    2531       </p>
    2532       <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
     2542      <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
     2543      <p id="rfc.section.11.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a> of this document.
     2544      </p>
     2545      <p id="rfc.section.11.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    25332546      </p>
    25342547      <div id="rfc.table.2">
    … …  
    27622775         </table>
    27632776      </div>
    2764       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2765       <p id="rfc.section.10.3.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; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2777      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     2778      <p id="rfc.section.11.3.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; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    27662779      </p>
    27672780      <div id="rfc.table.3">
    … …  
    27812794                  <td class="left">http</td>
    27822795                  <td class="left">standard</td>
    2783                   <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section&nbsp;9.1</a>
     2796                  <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section&nbsp;10.1</a>
    27842797                  </td>
    27852798               </tr>
    … …  
    27882801                  <td class="left">http</td>
    27892802                  <td class="left">standard</td>
    2790                   <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;9.2</a>
     2803                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;10.2</a>
    27912804                  </td>
    27922805               </tr>
    … …  
    27952808                  <td class="left">http</td>
    27962809                  <td class="left">standard</td>
    2797                   <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;9.3</a>
     2810                  <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;10.3</a>
    27982811                  </td>
    27992812               </tr>
    … …  
    28022815                  <td class="left">http</td>
    28032816                  <td class="left">standard</td>
    2804                   <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section&nbsp;9.4</a>
     2817                  <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section&nbsp;10.4</a>
    28052818                  </td>
    28062819               </tr>
    … …  
    28092822                  <td class="left">http</td>
    28102823                  <td class="left">standard</td>
    2811                   <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;9.5</a>
     2824                  <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;10.5</a>
    28122825                  </td>
    28132826               </tr>
    … …  
    28162829                  <td class="left">http</td>
    28172830                  <td class="left">standard</td>
    2818                   <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section&nbsp;9.6</a>
     2831                  <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section&nbsp;10.6</a>
    28192832                  </td>
    28202833               </tr>
    … …  
    28232836                  <td class="left">http</td>
    28242837                  <td class="left">standard</td>
    2825                   <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section&nbsp;9.7</a>
     2838                  <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section&nbsp;10.7</a>
    28262839                  </td>
    28272840               </tr>
    … …  
    28302843                  <td class="left">http</td>
    28312844                  <td class="left">standard</td>
    2832                   <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;9.8</a>
     2845                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;10.8</a>
    28332846                  </td>
    28342847               </tr>
    … …  
    28372850                  <td class="left">http</td>
    28382851                  <td class="left">standard</td>
    2839                   <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section&nbsp;9.9</a>
     2852                  <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section&nbsp;10.9</a>
    28402853                  </td>
    28412854               </tr>
    … …  
    28442857                  <td class="left">http</td>
    28452858                  <td class="left">standard</td>
    2846                   <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;9.10</a>
     2859                  <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;10.10</a>
    28472860                  </td>
    28482861               </tr>
    … …  
    28502863         </table>
    28512864      </div>
    2852       <p id="rfc.section.10.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    2853       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    2854       <p id="rfc.section.11.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
     2865      <p id="rfc.section.11.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     2866      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     2867      <p id="rfc.section.12.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    28552868         as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    28562869         make some suggestions for reducing security risks.
    28572870      </p>
    2858       <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
    2859       <p id="rfc.section.11.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
     2871      <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a>&nbsp;<a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
     2872      <p id="rfc.section.12.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
    28602873         a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    28612874         Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth
    28622875         special mention in this context: Server, Via, Referer and From.
    28632876      </p>
    2864       <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
     2877      <p id="rfc.section.12.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    28652878         against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option.
    28662879      </p>
    2867       <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
     2880      <p id="rfc.section.12.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
    28682881         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    28692882      </p>
    2870       <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
     2883      <p id="rfc.section.12.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
    28712884         power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
    28722885         information has been removed, the Referer header field might indicate a private document's URI whose publication would be
    28732886         inappropriate.
    28742887      </p>
    2875       <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
     2888      <p id="rfc.section.12.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
    28762889         hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    28772890      </p>
    2878       <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
     2891      <p id="rfc.section.12.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    28792892         of From and Referer information.
    28802893      </p>
    2881       <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     2894      <p id="rfc.section.12.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;10.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;10.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    28822895         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    28832896         no better mechanism.
    28842897      </p>
    2885       <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,
     2898      <p id="rfc.section.12.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,
    28862899         to uniquely identify the user.
    28872900      </p>
    2888       <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
     2901      <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
    28892902         to collect data from the client.
    28902903      </p>
    2891       <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    2892       <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
     2904      <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
     2905      <p id="rfc.section.12.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
    28932906         recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could
    28942907         have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From
    28952908         information.
    28962909      </p>
    2897       <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    2898       </p>
    2899       <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
     2910      <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
     2911      </p>
     2912      <p id="rfc.section.12.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
    29002913         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
    29012914         Such services can use POST-based form submission instead.
    29022915      </p>
    2903       <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    2904       <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
     2916      <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
     2917      <p id="rfc.section.12.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    29052918         to make sure that they do not attempt to invalidate resources over which they have no authority.
    29062919      </p>
    2907       <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
     2920      <p id="rfc.section.12.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
    29082921         confidential information to the target server — although the fragment identifier is not transmitted in the final request,
    29092922         it might be visible to the user agent through other means, such as scripting.
    29102923      </p>
    2911       <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
     2924      <h2 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a>&nbsp;Security Considerations for CONNECT
    29122925      </h2>
    2913       <p id="rfc.section.11.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
     2926      <p id="rfc.section.12.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
    29142927         A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    29152928      </p>
    2916       <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2917       <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    2918       </p>
    2919       <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References
     2929      <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     2930      <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     2931      </p>
     2932      <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References
    29202933      </h1>
    2921       <h2 id="rfc.references.1"><a href="#rfc.section.13.1" id="rfc.section.13.1">13.1</a> Normative References
     2934      <h2 id="rfc.references.1"><a href="#rfc.section.14.1" id="rfc.section.14.1">14.1</a> Normative References
    29222935      </h2>
    29232936      <table>                 
    … …  
    29682981         </tr>
    29692982      </table>
    2970       <h2 id="rfc.references.2"><a href="#rfc.section.13.2" id="rfc.section.13.2">13.2</a> Informative References
     2983      <h2 id="rfc.references.2"><a href="#rfc.section.14.2" id="rfc.section.14.2">14.2</a> Informative References
    29712984      </h2>
    29722985      <table>                   
    … …  
    30633076      <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;7.4.15</a>)
    30643077      </p>
    3065       <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
     3078      <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;10</a>)
    30663079      </p>
    30673080      <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
    3068          on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.1</a>)
     3081         on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;10.1</a>)
    30693082      </p>
    30703083      <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
    3071          (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.3</a>)
     3084         (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;10.3</a>)
    30723085      </p>
    30733086      <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    30743087         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    3075          (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.5</a>)
    3076       </p>
    3077       <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.6</a>)
    3078       </p>
    3079       <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.7</a>)
     3088         (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;10.5</a>)
     3089      </p>
     3090      <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;10.6</a>)
     3091      </p>
     3092      <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;10.7</a>)
    30803093      </p>
    30813094      <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3082          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>)
     3095         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;10.9</a>)
    30833096      </p>
    30843097      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3085       <div id="rfc.figure.u.36"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
     3098      <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
    30863099
    30873100<a href="#core.rules" class="smpl">BWS</a> = &lt;BWS, defined in [Part1], Section 3.2.1&gt;
    … …  
    31673180
    31683181<a href="#abnf.dependencies" class="smpl">partial-URI</a> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    3169 <a href="#abnf.dependencies" class="smpl">product</a> = &lt;product, defined in [Part1], Section 5.2&gt;
     3182<a href="#product.tokens" class="smpl">product</a> = &lt;product, defined in [Part1], Section 5.2&gt;
    31703183
    31713184<a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.4&gt;
    … …  
    31803193
    31813194<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    3182 </pre> <div id="rfc.figure.u.37"></div>
     3195</pre> <div id="rfc.figure.u.39"></div>
    31833196      <p>ABNF diagnostics:</p><pre class="inline">; Allow defined but not used
    31843197; Date defined but not used
    … …  
    35103523         <ul class="ind">
    35113524            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    3512                   <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li>
    3513                   <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.87"><b>9.3</b></a></li>
    3514                   <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li>
     3525                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li>
     3526                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.89"><b>10.3</b></a></li>
     3527                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li>
    35153528               </ul>
    35163529            </li>
    35173530            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    3518                   <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">10.2</a></li>
    3519                   <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li>
    3520                   <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li>
    3521                   <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
    3522                   <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li>
    3523                   <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li>
     3531                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li>
     3532                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li>
     3533                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li>
     3534                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
     3535                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li>
     3536                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li>
    35243537               </ul>
    35253538            </li>
    35263539            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    3527                   <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">10.2</a></li>
    3528                   <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">10.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
    3529                   <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">10.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
    3530                   <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">10.2</a></li>
    3531                   <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">10.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
    3532                   <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">10.2</a></li>
    3533                   <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">10.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
     3540                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li>
     3541                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
     3542                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
     3543                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li>
     3544                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
     3545                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li>
     3546                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
    35343547               </ul>
    35353548            </li>
    35363549            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    3537                   <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">10.2</a></li>
    3538                   <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">10.2</a></li>
    3539                   <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">10.2</a></li>
    3540                   <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">10.2</a></li>
    3541                   <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">10.2</a></li>
    3542                   <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">10.2</a></li>
    3543                   <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">10.2</a></li>
    3544                   <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">10.2</a></li>
    3545                   <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">10.2</a></li>
    3546                   <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">10.2</a></li>
    3547                   <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">10.2</a></li>
    3548                   <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">10.2</a></li>
    3549                   <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">10.2</a></li>
    3550                   <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">10.2</a></li>
    3551                   <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">10.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
     3550                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li>
     3551                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li>
     3552                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li>
     3553                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li>
     3554                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li>
     3555                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li>
     3556                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li>
     3557                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li>
     3558                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li>
     3559                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li>
     3560                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li>
     3561                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li>
     3562                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li>
     3563                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li>
     3564                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
    35523565               </ul>
    35533566            </li>
    35543567            <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
    3555                   <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">10.2</a></li>
    3556                   <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">10.2</a></li>
    3557                   <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">10.2</a></li>
    3558                   <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">10.2</a></li>
    3559                   <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">10.2</a></li>
    3560                   <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">10.2</a></li>
     3568                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li>
     3569                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li>
     3570                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li>
     3571                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li>
     3572                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li>
     3573                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li>
    35613574               </ul>
    35623575            </li>
    35633576            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3564                   <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
     3577                  <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
    35653578               </ul>
    35663579            </li>
    35673580            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    3568                   <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">10.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
     3581                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
    35693582               </ul>
    35703583            </li>
    35713584            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3572                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>
    3573                   <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">10.1</a></li>
     3585                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li>
     3586                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>
    35743587               </ul>
    35753588            </li>
    35763589            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3577                   <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
     3590                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.e.1"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
    35783591                  <li>Expect Values&nbsp;&nbsp;
    35793592                     <ul>
    3580                         <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>9.3</b></a></li>
     3593                        <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>10.3</b></a></li>
    35813594                     </ul>
    35823595                  </li>
    … …  
    35843597            </li>
    35853598            <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul>
    3586                   <li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>
     3599                  <li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li>
    35873600               </ul>
    35883601            </li>
    35893602            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    3590                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">10.1</a></li>
     3603                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>
    35913604                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    35923605                     <ul>
    3593                         <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>9.1</b></a></li>
     3606                        <li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>10.1</b></a></li>
    35943607                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>8</b></a></li>
    3595                         <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>9.2</b></a></li>
     3608                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>10.2</b></a></li>
    35963609                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>8</b></a></li>
    35973610                        <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>8</b></a></li>
    35983611                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>8</b></a></li>
    35993612                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>8</b></a></li>
    3600                         <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>9.8</b></a></li>
    3601                         <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>9.3</b></a></li>
    3602                         <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>9.3</b></a></li>
    3603                         <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>9.3</b></a></li>
    3604                         <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>9.3</b></a></li>
    3605                         <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>9.3</b></a></li>
     3613                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>10.8</b></a></li>
     3614                        <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>10.3</b></a></li>
     3615                        <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>10.3</b></a></li>
     3616                        <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>10.3</b></a></li>
     3617                        <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>10.3</b></a></li>
     3618                        <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>10.3</b></a></li>
    36063619                        <li><tt>extension-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>4</b></a></li>
    3607                         <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>9.4</b></a></li>
     3620                        <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>10.4</b></a></li>
    36083621                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>8</b></a></li>
    36093622                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>8</b></a></li>
    36103623                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>8</b></a></li>
    3611                         <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>9.5</b></a></li>
    3612                         <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>9.6</b></a></li>
     3624                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>10.5</b></a></li>
     3625                        <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>10.6</b></a></li>
    36133626                        <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2</b></a></li>
    36143627                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>8</b></a></li>
    36153628                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>8</b></a></li>
    36163629                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>8</b></a></li>
     3630                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>9</b></a></li>
     3631                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>9</b></a></li>
    36173632                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>4</b></a></li>
    3618                         <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>9.7</b></a></li>
    3619                         <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>9.8</b></a></li>
     3633                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>10.7</b></a></li>
     3634                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>10.8</b></a></li>
    36203635                        <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>8</b></a></li>
    36213636                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>8</b></a></li>
    36223637                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>8</b></a></li>
    3623                         <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>9.9</b></a></li>
     3638                        <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>10.9</b></a></li>
    36243639                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>4</b></a></li>
    36253640                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>8</b></a></li>
    3626                         <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>9.10</b></a></li>
     3641                        <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>10.10</b></a></li>
    36273642                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>8</b></a></li>
    36283643                     </ul>
    … …  
    36313646            </li>
    36323647            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    3633                   <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">10.1</a></li>
     3648                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>
    36343649                  <li>Header Fields&nbsp;&nbsp;
    36353650                     <ul>
    3636                         <li>Allow&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>9.1</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
    3637                         <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>9.2</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>
    3638                         <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.h.4"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
    3639                         <li>From&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>9.4</b></a>, <a href="#rfc.xref.header.from.2">10.3</a></li>
    3640                         <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
    3641                         <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b>9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
    3642                         <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
    3643                         <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
    3644                         <li>Server&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
    3645                         <li>User-Agent&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>9.10</b></a>, <a href="#rfc.xref.header.user-agent.2">10.3</a>, <a href="#rfc.xref.header.user-agent.3">11.1</a></li>
     3651                        <li>Allow&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>
     3652                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li>
     3653                        <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>
     3654                        <li>From&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li>
     3655                        <li>Location&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
     3656                        <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
     3657                        <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
     3658                        <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li>
     3659                        <li>Server&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
     3660                        <li>User-Agent&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>10.10</b></a>, <a href="#rfc.xref.header.user-agent.2">11.3</a>, <a href="#rfc.xref.header.user-agent.3">12.1</a></li>
    36463661                     </ul>
    36473662                  </li>
    … …  
    36533668            </li>
    36543669            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    3655                   <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b>9.5</b></a>, <a href="#rfc.xref.header.location.4">10.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
     3670                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>
    36563671               </ul>
    36573672            </li>
    36583673            <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul>
    3659                   <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>9.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
     3674                  <li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
    36603675                  <li>Methods&nbsp;&nbsp;
    36613676                     <ul>
    3662                         <li>CONNECT&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">10.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
    3663                         <li>DELETE&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">10.1</a></li>
    3664                         <li>GET&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">10.1</a></li>
    3665                         <li>HEAD&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">10.1</a></li>
    3666                         <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>
    3667                         <li>POST&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">10.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
    3668                         <li>PUT&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">10.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
    3669                         <li>TRACE&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">9.6</a>, <a href="#rfc.xref.TRACE.3">10.1</a>, <a href="#rfc.xref.TRACE.4">11.1</a></li>
     3677                        <li>CONNECT&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li>
     3678                        <li>DELETE&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li>
     3679                        <li>GET&nbsp;&nbsp;<a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li>
     3680                        <li>HEAD&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li>
     3681                        <li>OPTIONS&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>
     3682                        <li>POST&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
     3683                        <li>PUT&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
     3684                        <li>TRACE&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">10.6</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li>
    36703685                     </ul>
    36713686                  </li>
    … …  
    36733688            </li>
    36743689            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    3675                   <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">9.6</a>, <a href="#rfc.xref.OPTIONS.3">10.1</a></li>
     3690                  <li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li>
    36763691               </ul>
    36773692            </li>
    36783693            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3679                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.28">5.1</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.15</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">9.10</a>, <a href="#rfc.xref.Part1.44">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.45">A</a><ul>
     3694                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.15</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">10.3</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a>, <a href="#rfc.xref.Part1.41">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.42">A</a><ul>
    36803695                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    36813696                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    3682                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">7.2.4</a></li>
    3683                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">7.5.6</a></li>
    3684                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a></li>
    3685                         <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">6.9</a></li>
     3697                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.2.4</a></li>
     3698                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">7.5.6</a></li>
     3699                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li>
     3700                        <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.9</a></li>
    36863701                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li>
    3687                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">9.10</a></li>
    3688                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.20">3.1</a></li>
    3689                         <li><em>Section 3.2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">3.1</a></li>
    3690                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li>
    3691                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.28">5.1</a></li>
    3692                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.1</a></li>
    3693                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li>
    3694                         <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">9.3</a></li>
    3695                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    3696                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
    3697                         <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">3.2</a></li>
    3698                         <li><em>Section 8.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li>
    3699                         <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.45">A</a></li>
    3700                         <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.8</a></li>
    3701                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">12</a></li>
     3702                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a></li>
     3703                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.19">3.1</a></li>
     3704                        <li><em>Section 3.2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3.1</a></li>
     3705                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>
     3706                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
     3707                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
     3708                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3709                        <li><em>Section 7.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li>
     3710                        <li><em>Section 9.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
     3711                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
     3712                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li>
     3713                        <li><em>Section 9.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li>
     3714                        <li><em>Section 10.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li>
     3715                        <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">13</a></li>
    37023716                     </ul>
    37033717                  </li>
    3704                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13">9.5</a>, <a href="#Part3"><b>13.1</b></a><ul>
     3718                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13">10.5</a>, <a href="#Part3"><b>14.1</b></a><ul>
    37053719                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.1</a></li>
    37063720                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.11">7.3.1</a></li>
    … …  
    37113725                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">3.2</a></li>
    37123726                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.6">3.2</a></li>
    3713                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.13">9.5</a></li>
     3727                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.13">10.5</a></li>
    37143728                        <li><em>Section 6.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.9">7</a></li>
    37153729                     </ul>
    37163730                  </li>
    3717                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>
     3731                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul>
    37183732                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li>
    37193733                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a></li>
    … …  
    37263740                     </ul>
    37273741                  </li>
    3728                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>13.1</b></a><ul>
     3742                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>14.1</b></a><ul>
    37293743                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.1</a></li>
    37303744                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.5">4.1</a></li>
    … …  
    37353749                     </ul>
    37363750                  </li>
    3737                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>13.1</b></a><ul>
     3751                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>14.1</b></a><ul>
    37383752                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">6.5</a></li>
    37393753                        <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a></li>
    … …  
    37453759                     </ul>
    37463760                  </li>
    3747                   <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>13.1</b></a><ul>
     3761                  <li><em>Part7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>14.1</b></a><ul>
    37483762                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.5">4.1</a></li>
    37493763                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.6">4.1</a></li>
    … …  
    37553769                     </ul>
    37563770                  </li>
    3757                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">10.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
    3758                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">10.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
     3771                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li>
     3772                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li>
    37593773               </ul>
    37603774            </li>
    37613775            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    3762                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>9.7</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
    3763                   <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>9.8</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
    3764                   <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">8</a>, <a href="#rfc.xref.RFC1123.2">8</a>, <a href="#RFC1123"><b>13.2</b></a><ul>
     3776                  <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
     3777                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li>
     3778                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">8</a>, <a href="#rfc.xref.RFC1123.2">8</a>, <a href="#RFC1123"><b>14.2</b></a><ul>
    37653779                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">8</a></li>
    37663780                     </ul>
    37673781                  </li>
    3768                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">7.3</a>, <a href="#RFC1945"><b>13.2</b></a><ul>
     3782                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">7.3</a>, <a href="#RFC1945"><b>14.2</b></a><ul>
    37693783                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">7.3</a></li>
    37703784                     </ul>
    37713785                  </li>
    3772                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>13.2</b></a><ul>
     3786                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>14.2</b></a><ul>
    37733787                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.3</a></li>
    37743788                        <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.3</a></li>
    37753789                     </ul>
    37763790                  </li>
    3777                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li>
    3778                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7.3</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>
     3791                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>14.1</b></a></li>
     3792                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7.3</a>, <a href="#RFC2616"><b>14.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul>
    37793793                        <li><em>Section 10.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.2">7.3</a></li>
    37803794                     </ul>
    37813795                  </li>
    3782                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>
    3783                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li>
     3796                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#RFC2817"><b>14.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul>
     3797                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li>
    37843798                     </ul>
    37853799                  </li>
    3786                   <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">10.3</a>, <a href="#RFC3864"><b>13.2</b></a><ul>
     3800                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">11.3</a>, <a href="#RFC3864"><b>14.2</b></a><ul>
    37873801                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.2">3.1</a></li>
    37883802                     </ul>
    37893803                  </li>
    3790                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">9.5</a>, <a href="#rfc.xref.RFC3986.2">9.5</a>, <a href="#RFC3986"><b>13.1</b></a><ul>
    3791                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">9.5</a></li>
    3792                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">9.5</a></li>
     3804                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">10.5</a>, <a href="#rfc.xref.RFC3986.2">10.5</a>, <a href="#RFC3986"><b>14.1</b></a><ul>
     3805                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">10.5</a></li>
     3806                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">10.5</a></li>
    37933807                     </ul>
    37943808                  </li>
    3795                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>13.2</b></a><ul>
     3809                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>14.2</b></a><ul>
    37963810                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a></li>
    37973811                     </ul>
    37983812                  </li>
    3799                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>13.1</b></a><ul>
     3813                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>14.1</b></a><ul>
    38003814                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
    38013815                     </ul>
    38023816                  </li>
    3803                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">8</a>, <a href="#rfc.xref.RFC5322.2">9.2</a>, <a href="#rfc.xref.RFC5322.3">9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a>, <a href="#RFC5322"><b>13.2</b></a><ul>
     3817                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">8</a>, <a href="#rfc.xref.RFC5322.2">10.2</a>, <a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a>, <a href="#RFC5322"><b>14.2</b></a><ul>
    38043818                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">8</a></li>
    3805                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">9.4</a>, <a href="#rfc.xref.RFC5322.4">9.4</a></li>
    3806                         <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.2">9.2</a></li>
     3819                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a></li>
     3820                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.2">10.2</a></li>
    38073821                     </ul>
    38083822                  </li>
    3809                   <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>13.2</b></a></li>
    3810                   <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>13.2</b></a></li>
     3823                  <li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>14.2</b></a></li>
     3824                  <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>14.2</b></a></li>
    38113825               </ul>
    38123826            </li>
    38133827            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    38143828                  <li>Safe Methods&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>6.1.1</b></a></li>
    3815                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>9.9</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
     3829                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
    38163830                  <li>Status Codes&nbsp;&nbsp;
    38173831                     <ul>
    3818                         <li>100 Continue&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.2"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li>
    3819                         <li>101 Switching Protocols&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.3"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li>
    3820                         <li>200 OK&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">10.2</a></li>
    3821                         <li>201 Created&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">10.2</a></li>
    3822                         <li>202 Accepted&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">10.2</a></li>
    3823                         <li>203 Non-Authoritative Information&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">10.2</a>, <a href="#rfc.xref.status.203.3">A</a></li>
    3824                         <li>204 No Content&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">10.2</a></li>
    3825                         <li>205 Reset Content&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">10.2</a></li>
    3826                         <li>300 Multiple Choices&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.10"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">10.2</a></li>
    3827                         <li>301 Moved Permanently&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.11"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">10.2</a>, <a href="#rfc.xref.status.301.3">A</a></li>
    3828                         <li>302 Found&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.12"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">10.2</a>, <a href="#rfc.xref.status.302.3">A</a></li>
    3829                         <li>303 See Other&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.13"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">10.2</a></li>
    3830                         <li>305 Use Proxy&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.14"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">10.2</a>, <a href="#rfc.xref.status.305.3">A</a></li>
    3831                         <li>306 (Unused)&nbsp;&nbsp;<a href="#rfc.iref.s.15"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">10.2</a></li>
    3832                         <li>307 Temporary Redirect&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.16"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">10.2</a>, <a href="#rfc.xref.status.307.3">A</a></li>
    3833                         <li>400 Bad Request&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.17"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">10.2</a></li>
    3834                         <li>402 Payment Required&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.18"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">10.2</a></li>
    3835                         <li>403 Forbidden&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.19"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">10.2</a></li>
    3836                         <li>404 Not Found&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.20"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">10.2</a></li>
    3837                         <li>405 Method Not Allowed&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.21"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">10.2</a></li>
    3838                         <li>406 Not Acceptable&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.22"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">10.2</a></li>
    3839                         <li>408 Request Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.23"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">10.2</a></li>
    3840                         <li>409 Conflict&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.24"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">10.2</a></li>
    3841                         <li>410 Gone&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.25"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">10.2</a></li>
    3842                         <li>411 Length Required&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.26"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">10.2</a></li>
    3843                         <li>413 Request Representation Too Large&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.27"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">10.2</a></li>
    3844                         <li>414 URI Too Long&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.28"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">10.2</a></li>
    3845                         <li>415 Unsupported Media Type&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.29"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">10.2</a></li>
    3846                         <li>417 Expectation Failed&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.30"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">10.2</a></li>
    3847                         <li>426 Upgrade Required&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.31"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">10.2</a>, <a href="#rfc.xref.status.426.3">A</a></li>
    3848                         <li>500 Internal Server Error&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.32"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">10.2</a></li>
    3849                         <li>501 Not Implemented&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.33"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">10.2</a></li>
    3850                         <li>502 Bad Gateway&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.34"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">10.2</a></li>
    3851                         <li>503 Service Unavailable&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.35"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">10.2</a></li>
    3852                         <li>504 Gateway Timeout&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.36"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">10.2&