Ignore:
Timestamp:
Feb 18, 2012, 2:29:16 AM (8 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.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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>
Note: See TracChangeset for help on using the changeset viewer.