Ignore:
Timestamp:
10/03/12 07:18:43 (11 years ago)
Author:
fielding@…
Message:

(editorial) move transfer codings section up to be next to message parsing

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1572 r1574  
    485485      <link rel="Chapter" title="2 Architecture" href="#rfc.section.2">
    486486      <link rel="Chapter" title="3 Message Format" href="#rfc.section.3">
    487       <link rel="Chapter" title="4 Message Routing" href="#rfc.section.4">
    488       <link rel="Chapter" title="5 Transfer Codings" href="#rfc.section.5">
     487      <link rel="Chapter" title="4 Transfer Codings" href="#rfc.section.4">
     488      <link rel="Chapter" title="5 Message Routing" 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">
    … …  
    698698            </ul>
    699699         </li>
    700          <li>4.&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
    701                <li>4.1&nbsp;&nbsp;&nbsp;<a href="#request-target-types">Types of Request Target</a></li>
    702                <li>4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    703                <li>4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    704                <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    705             </ul>
    706          </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>
     700         <li>4.&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
     701               <li>4.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
     702               <li>4.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
     703                     <li>4.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
     704                     <li>4.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
     705                     <li>4.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    713706                  </ul>
    714707               </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>
     708               <li>4.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     709               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a><ul>
     710                     <li>4.4.1&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
    718711                  </ul>
    719712               </li>
    720                <li>5.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     713               <li>4.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     714            </ul>
     715         </li>
     716         <li>5.&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
     717               <li>5.1&nbsp;&nbsp;&nbsp;<a href="#request-target-types">Types of Request Target</a></li>
     718               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
     719               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
     720               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    721721            </ul>
    722722         </li>
    … …  
    11541154      </p>
    11551155      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1156          and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1156         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11571157      </p>
    11581158      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    … …  
    12521252      <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h4>
    12531253      <p id="rfc.section.3.1.1.2.p.1">The request-target identifies the target resource upon which to apply the request. The four options for request-target are
    1254          described in <a href="#request-target-types" title="Types of Request Target">Section&nbsp;4.1</a>.
     1254         described in <a href="#request-target-types" title="Types of Request Target">Section&nbsp;5.1</a>.
    12551255      </p>
    12561256      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    … …  
    13771377      <div id="rule.token.separators">
    13781378         <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.
    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>).
     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;4</a>).
    13801380         </p>
    13811381      </div>
    … …  
    14711471      <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header
    14721472         field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined
    1473          in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
     1473         in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>.
    14741474      </p>
    14751475      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    … …  
    14791479         applied for transport efficiency or security from those that are characteristics of the target resource.
    14801480      </p>
    1481       <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
     1481      <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
    14821482         is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding
    14831483         applied <em class="bcp14">MUST</em> be "chunked". If any 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.
    … …  
    15461546         </li>
    15471547         <li>
    1548             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">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
     1548            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
    15491549               indicates the data is complete.
    15501550            </p>
    … …  
    16301630         above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response.
    16311631      </p>
    1632       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
    1633       <p id="rfc.section.4.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target
    1634          resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target.
    1635       </p>
    1636       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
    1637       <p id="rfc.section.4.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the
    1638          request is being made to a proxy.
    1639       </p>
    1640       <div id="origin-form">
    1641          <p id="rfc.section.4.1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a
    1642             resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified
    1643             as
    1644          </p>
    1645       </div>
    1646       <div id="rfc.figure.u.38"></div><pre>http://www.example.org/where?q=now
    1647 </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
    1648          lines:
    1649       </p>
    1650       <div id="rfc.figure.u.39"></div><pre class="text2">GET /where?q=now HTTP/1.1
    1651 Host: www.example.org
    1652 </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.
    1653          If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
    1654       </p>
    1655       <p id="rfc.section.4.1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
    1656       </p>
    1657       <div id="absolute-URI-form">
    1658          <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
    1659             cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    1660             loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
    1661             An example request-line would be:
    1662          </p>
    1663       </div>
    1664       <div id="rfc.figure.u.40"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1665 </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.
    1666       </p>
    1667       <p id="rfc.section.4.1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    1668       </p>
    1669       <div id="authority-form">
    1670          <p id="rfc.section.4.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,
    1671          </p>
    1672       </div>
    1673       <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    1674 </pre><div id="asterix-form">
    1675          <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
    1676             process) rather than to a specific named resource at that server. For example,
    1677          </p>
    1678       </div>
    1679       <div id="rfc.figure.u.42"></div><pre class="text2">OPTIONS * HTTP/1.1
    1680 </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
    1681          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.
    1682       </p>
    1683       <div id="rfc.figure.u.43"></div>
    1684       <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1685 </pre><div id="rfc.figure.u.44"></div>
    1686       <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    1687 Host: www.example.org:8001
    1688 </pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1689       <p id="rfc.section.4.1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
    1690          except as noted above to replace a null path-absolute with "/" or "*".
    1691       </p>
    1692       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
    1693       <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header
    1694          field.
    1695       </p>
    1696       <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix&nbsp;A.1.1</a> for other requirements on Host support in HTTP/1.1.)
    1697       </p>
    1698       <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
    1699          vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
    1700       </p>
    1701       <ol>
    1702          <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
    1703          </li>
    1704          <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the
    1705             Host header field value.
    1706          </li>
    1707          <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
    1708          </li>
    1709       </ol>
    1710       <p id="rfc.section.4.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
    1711          what exact resource is being requested.
    1712       </p>
    1713       <div id="rfc.iref.e.1"></div>
    1714       <div id="rfc.iref.t.5"></div>
    1715       <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>
    1716       <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
    1717          context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
    1718          by the effective request URI.
    1719       </p>
    1720       <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
    1721       <p id="rfc.section.4.3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective
    1722          request URI is constructed by concatenating
    1723       </p>
    1724       <p id="rfc.section.4.3.p.4"> </p>
    1725       <ul>
    1726          <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured
    1727             TCP connection,
    1728          </li>
    1729          <li>the octet sequence "://",</li>
    1730          <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
    1731          </li>
    1732          <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
    1733       </ul>
    1734       <p id="rfc.section.4.3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective
    1735          request URI is undefined.
    1736       </p>
    1737       <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    1738       <div id="rfc.figure.u.45"></div>
    1739       <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    1740 Host: www.example.org:8080
    1741 </pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
    1742          the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    1743       </p>
    1744       <div id="rfc.figure.u.46"></div>
    1745       <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
    1746 Host: www.example.org
    1747 </pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
    1748          thus "https://www.example.org".
    1749       </p>
    1750       <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
    1751       </p>
    1752       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    1753       <p id="rfc.section.4.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    1754          messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1755          on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    1756          see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
    1757       </p>
    1758       <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.
    1759       </p>
    1760       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
    1761       <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
     1632      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
     1633      <p id="rfc.section.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
    17621634         to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
    17631635         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    17641636      </p>
    1765       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>    = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>
    1766                      / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.1</a>
    1767                      / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2</a>
    1768                      / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.3</a>
     1637      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>    = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>
     1638                     / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;4.2.1</a>
     1639                     / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>
     1640                     / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;4.2.3</a>
    17691641                     / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    17701642  <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">transfer-parameter</a> )
    17711643</pre><div id="rule.parameter">
    1772          <p id="rfc.section.5.p.3">      Parameters are in the form of attribute/value pairs.</p>
     1644         <p id="rfc.section.4.p.3">      Parameters are in the form of attribute/value pairs.</p>
    17731645      </div>
    1774       <div id="rfc.figure.u.48"></div><pre class="inline"><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><span id="rfc.iref.g.61"></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>
     1646      <div id="rfc.figure.u.39"></div><pre class="inline"><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><span id="rfc.iref.g.61"></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>
    17751647  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    17761648  <a href="#rule.parameter" class="smpl">value</a>              = <a href="#rule.token.separators" class="smpl">word</a>
    1777 </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>).
     1649</pre><p id="rfc.section.4.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;4.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>).
    17781650      </p>
    17791651      <div id="rfc.iref.c.7"></div>
    17801652      <div id="rfc.iref.c.8"></div>
    1781       <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>
    1782       <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
     1653      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2>
     1654      <p id="rfc.section.4.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
    17831655         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
    17841656         for the recipient to verify that it has received the full message.
    17851657      </p>
    1786       <div id="rfc.figure.u.49"></div><pre class="inline"><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><span id="rfc.iref.g.72"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1658      <div id="rfc.figure.u.40"></div><pre class="inline"><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><span id="rfc.iref.g.72"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    17871659                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    17881660                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
    … …  
    18031675                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    18041676  <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>
    1805 </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
     1677</pre><p id="rfc.section.4.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
    18061678         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    18071679      </p>
    1808       <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
    1809          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>).
    1810       </p>
    1811       <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:
     1680      <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     1681         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;4.5</a>).
     1682      </p>
     1683      <p id="rfc.section.4.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:
    18121684      </p>
    18131685      <ol>
    18141686         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
    1815             described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;5.4</a>; or,
     1687            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.4</a>; or,
    18161688         </li>
    18171689         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
    … …  
    18211693         </li>
    18221694      </ol>
    1823       <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
     1695      <p id="rfc.section.4.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    18241696         forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly
    18251697         infinite buffer on the proxy.
    18261698      </p>
    1827       <p id="rfc.section.5.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1828       <div id="rfc.figure.u.50"></div><pre class="text">  length := 0
     1699      <p id="rfc.section.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1700      <div id="rfc.figure.u.41"></div><pre class="text">  length := 0
    18291701  read chunk-size, chunk-ext (if any) and CRLF
    18301702  while (chunk-size &gt; 0) {
    … …  
    18411713  Content-Length := length
    18421714  Remove "chunked" from Transfer-Encoding
    1843 </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.
    1844       </p>
    1845       <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.
    1846       </p>
    1847       <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>
    1848       <p id="rfc.section.5.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
    1849       <div class="note" id="rfc.section.5.2.p.2">
     1715</pre><p id="rfc.section.4.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.
     1716      </p>
     1717      <p id="rfc.section.4.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.
     1718      </p>
     1719      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
     1720      <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
     1721      <div class="note" id="rfc.section.4.2.p.2">
    18501722         <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
    18511723            Their use here is representative of historical practice, not good design.
    18521724         </p>
    18531725      </div>
    1854       <div class="note" id="rfc.section.5.2.p.3">
     1726      <div class="note" id="rfc.section.4.2.p.3">
    18551727         <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.
    18561728         </p>
    … …  
    18581730      <div id="rfc.iref.c.9"></div>
    18591731      <div id="rfc.iref.c.10"></div>
    1860       <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>
    1861       <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
     1732      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h3>
     1733      <p id="rfc.section.4.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
    18621734         coding (LZW).
    18631735      </p>
    18641736      <div id="rfc.iref.d.2"></div>
    18651737      <div id="rfc.iref.c.11"></div>
    1866       <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>
    1867       <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>).
    1868       </p>
    1869       <div class="note" id="rfc.section.5.2.2.p.2">
     1738      <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h3>
     1739      <p id="rfc.section.4.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>).
     1740      </p>
     1741      <div class="note" id="rfc.section.4.2.2.p.2">
    18701742         <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper.
    18711743         </p>
    … …  
    18731745      <div id="rfc.iref.g.73"></div>
    18741746      <div id="rfc.iref.c.12"></div>
    1875       <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>
    1876       <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.
    1877       </p>
    1878       <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>
    1879       <p id="rfc.section.5.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
    1880       <p id="rfc.section.5.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     1747      <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3>
     1748      <p id="rfc.section.4.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.
     1749      </p>
     1750      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2>
     1751      <p id="rfc.section.4.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
     1752      <p id="rfc.section.4.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    18811753      </p>
    18821754      <ul>
    … …  
    18851757         <li>Pointer to specification text</li>
    18861758      </ul>
    1887       <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>).
    1888       </p>
    1889       <p id="rfc.section.5.3.p.4">Values to be added to this name space require IETF Review (see <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.
    1890       </p>
    1891       <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;.
    1892       </p>
    1893       <div id="rfc.iref.t.6"></div>
     1759      <p id="rfc.section.4.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;4.2</a>).
     1760      </p>
     1761      <p id="rfc.section.4.3.p.4">Values to be added to this name space require IETF Review (see <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.
     1762      </p>
     1763      <p id="rfc.section.4.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;.
     1764      </p>
     1765      <div id="rfc.iref.t.5"></div>
    18941766      <div id="rfc.iref.h.8"></div>
    1895       <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>
    1896       <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
     1767      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     1768      <p id="rfc.section.4.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
    18971769         or not it is willing to accept trailer fields in a chunked transfer-coding.
    18981770      </p>
    1899       <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
    1900          accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>).
    1901       </p>
    1902       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     1771      <p id="rfc.section.4.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     1772         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1773      </p>
     1774      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    19031775  <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> ] )
    19041776  <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    19051777  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    1906 </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,
    1907          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.
    1908       </p>
    1909       <p id="rfc.section.5.4.p.5">Examples of its use are:</p>
    1910       <div id="rfc.figure.u.52"></div><pre class="text">  TE: deflate
     1778</pre><p id="rfc.section.4.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     1779         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     1780      </p>
     1781      <p id="rfc.section.4.4.p.5">Examples of its use are:</p>
     1782      <div id="rfc.figure.u.43"></div><pre class="text">  TE: deflate
    19111783  TE:
    19121784  TE: trailers, deflate;q=0.5
    1913 </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.
    1914       </p>
    1915       <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>
     1785</pre><p id="rfc.section.4.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.
     1786      </p>
     1787      <p id="rfc.section.4.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    19161788      <ol>
    19171789         <li>
    … …  
    19271799         <li>
    19281800            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    1929                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".)
     1801               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;4.4.1</a>, a qvalue of 0 means "not acceptable".)
    19301802            </p>
    19311803         </li>
    … …  
    19361808         </li>
    19371809      </ol>
    1938       <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
     1810      <p id="rfc.section.4.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
    19391811         no transfer-coding is always acceptable.
    19401812      </p>
    1941       <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>
    1942       <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
     1813      <h3 id="rfc.section.4.4.1"><a href="#rfc.section.4.4.1">4.4.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
     1814      <p id="rfc.section.4.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;4.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
    19431815         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
    19441816         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.
    19451817      </p>
    1946       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.78"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1818      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.78"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    19471819                 / ( "1" [ "." 0*3("0") ] )
    1948 </pre><div class="note" id="rfc.section.5.4.1.p.3">
     1820</pre><div class="note" id="rfc.section.4.4.1.p.3">
    19491821         <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
    19501822         </p>
    19511823      </div>
    1952       <div id="rfc.iref.t.7"></div>
     1824      <div id="rfc.iref.t.6"></div>
    19531825      <div id="rfc.iref.h.9"></div>
    1954       <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>
    1955       <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
     1826      <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     1827      <p id="rfc.section.4.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
    19561828         chunked transfer-coding.
    19571829      </p>
    1958       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.79"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    1959 </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
     1830      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.79"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     1831</pre><p id="rfc.section.4.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
    19601832         to know which header fields to expect in the trailer.
    19611833      </p>
    1962       <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.
    1963       </p>
    1964       <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:
     1834      <p id="rfc.section.4.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;4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     1835      </p>
     1836      <p id="rfc.section.4.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    19651837      </p>
    19661838      <ul>
    … …  
    19691841         <li>Trailer</li>
    19701842      </ul>
     1843      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
     1844      <p id="rfc.section.5.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target
     1845         resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target.
     1846      </p>
     1847      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
     1848      <p id="rfc.section.5.1.p.1">The proper format choice of the four options available to request-target depends on the method being requested and if the
     1849         request is being made to a proxy.
     1850      </p>
     1851      <div id="origin-form">
     1852         <p id="rfc.section.5.1.p.2"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form") to access a
     1853            resource identified by an "http" (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) URI. In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target and the authority component (excluding any userinfo) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource identified
     1854            as
     1855         </p>
     1856      </div>
     1857      <div id="rfc.figure.u.46"></div><pre>http://www.example.org/where?q=now
     1858</pre><p id="rfc.section.5.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
     1859         lines:
     1860      </p>
     1861      <div id="rfc.figure.u.47"></div><pre class="text2">GET /where?q=now HTTP/1.1
     1862Host: www.example.org
     1863</pre><p id="rfc.section.5.1.p.6">followed by the remainder of the request. Note that the origin form of request-target always starts with an absolute path.
     1864         If the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
     1865      </p>
     1866      <p id="rfc.section.5.1.p.7">If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
     1867      </p>
     1868      <div id="absolute-URI-form">
     1869         <p id="rfc.section.5.1.p.8"><span id="rfc.iref.a.2"></span> The "absolute-URI" form of request-target is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
     1870            cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
     1871            loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
     1872            An example request-line would be:
     1873         </p>
     1874      </div>
     1875      <div id="rfc.figure.u.48"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1876</pre><p id="rfc.section.5.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.
     1877      </p>
     1878      <p id="rfc.section.5.1.p.11">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
     1879      </p>
     1880      <div id="authority-form">
     1881         <p id="rfc.section.5.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,
     1882         </p>
     1883      </div>
     1884      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     1885</pre><div id="asterix-form">
     1886         <p id="rfc.section.5.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
     1887            process) rather than to a specific named resource at that server. For example,
     1888         </p>
     1889      </div>
     1890      <div id="rfc.figure.u.50"></div><pre class="text2">OPTIONS * HTTP/1.1
     1891</pre><p id="rfc.section.5.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
     1892         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.
     1893      </p>
     1894      <div id="rfc.figure.u.51"></div>
     1895      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
     1896</pre><div id="rfc.figure.u.52"></div>
     1897      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
     1898Host: www.example.org:8001
     1899</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
     1900      <p id="rfc.section.5.1.p.19">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
     1901         except as noted above to replace a null path-absolute with "/" or "*".
     1902      </p>
     1903      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
     1904      <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header
     1905         field.
     1906      </p>
     1907      <p id="rfc.section.5.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix&nbsp;A.1.1</a> for other requirements on Host support in HTTP/1.1.)
     1908      </p>
     1909      <p id="rfc.section.5.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
     1910         vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
     1911      </p>
     1912      <ol>
     1913         <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
     1914         </li>
     1915         <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the
     1916            Host header field value.
     1917         </li>
     1918         <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
     1919         </li>
     1920      </ol>
     1921      <p id="rfc.section.5.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
     1922         what exact resource is being requested.
     1923      </p>
     1924      <div id="rfc.iref.e.1"></div>
     1925      <div id="rfc.iref.t.7"></div>
     1926      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
     1927      <p id="rfc.section.5.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
     1928         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
     1929         by the effective request URI.
     1930      </p>
     1931      <p id="rfc.section.5.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
     1932      <p id="rfc.section.5.3.p.3">If the request-target uses the origin form or the asterisk form, and the Host header field is present, then the effective
     1933         request URI is constructed by concatenating
     1934      </p>
     1935      <p id="rfc.section.5.3.p.4"> </p>
     1936      <ul>
     1937         <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over a SSL/TLS-secured
     1938            TCP connection,
     1939         </li>
     1940         <li>the octet sequence "://",</li>
     1941         <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
     1942         </li>
     1943         <li>the request-target obtained from the request-line, unless the request-target is just the asterisk "*".</li>
     1944      </ul>
     1945      <p id="rfc.section.5.3.p.5">If the request-target uses the origin form or the asterisk form, and the Host header field is not present, then the effective
     1946         request URI is undefined.
     1947      </p>
     1948      <p id="rfc.section.5.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
     1949      <div id="rfc.figure.u.53"></div>
     1950      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
     1951Host: www.example.org:8080
     1952</pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
     1953         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
     1954      </p>
     1955      <div id="rfc.figure.u.54"></div>
     1956      <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
     1957Host: www.example.org
     1958</pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
     1959         thus "https://www.example.org".
     1960      </p>
     1961      <p id="rfc.section.5.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
     1962      </p>
     1963      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
     1964      <p id="rfc.section.5.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
     1965         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
     1966         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
     1967         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
     1968      </p>
     1969      <p id="rfc.section.5.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.
     1970      </p>
    19711971      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    19721972      <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>
    … …  
    20932093         </p>
    20942094      </div>
    2095       <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>).
     2095      <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;4</a>).
    20962096      </p>
    20972097      <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>
    … …  
    21322132      <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>
    21332133      <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
    2134          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.
     2134         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;4</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.
    21352135      </p>
    21362136      <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>
    … …  
    22382238               <tr>
    22392239                  <td class="left">TE</td>
    2240                   <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;5.4</a></td>
     2240                  <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;4.4</a></td>
    22412241               </tr>
    22422242               <tr>
    22432243                  <td class="left">Trailer</td>
    2244                   <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;5.5</a></td>
     2244                  <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;4.5</a></td>
    22452245               </tr>
    22462246               <tr>
    … …  
    23282328         message that contains more than one Host header field or a Host header field with an invalid field-value.
    23292329      </p>
    2330       <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.
     2330      <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">5.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.
    23312331      </p>
    23322332      <div id="rfc.iref.u.5"></div>
    … …  
    24742474                  <td class="left">http</td>
    24752475                  <td class="left">standard</td>
    2476                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;5.4</a>
     2476                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;4.4</a>
    24772477                  </td>
    24782478               </tr>
    … …  
    24812481                  <td class="left">http</td>
    24822482                  <td class="left">standard</td>
    2483                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;5.5</a>
     2483                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;4.5</a>
    24842484                  </td>
    24852485               </tr>
    … …  
    26512651      </dl>
    26522652      <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>
    2653       <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.
     2653      <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;4.3</a> of this document.
    26542654      </p>
    26552655      <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:
    … …  
    26692669                  <td class="left">chunked</td>
    26702670                  <td class="left">Transfer in a series of chunks</td>
    2671                   <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>
     2671                  <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>
    26722672                  </td>
    26732673               </tr>
    … …  
    26752675                  <td class="left">compress</td>
    26762676                  <td class="left">UNIX "compress" program method</td>
    2677                   <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.1</a>
     2677                  <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;4.2.1</a>
    26782678                  </td>
    26792679               </tr>
    … …  
    26822682                  <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>)
    26832683                  </td>
    2684                   <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2</a>
     2684                  <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>
    26852685                  </td>
    26862686               </tr>
    … …  
    26882688                  <td class="left">gzip</td>
    26892689                  <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>
    2690                   <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.3</a>
     2690                  <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;4.2.3</a>
    26912691                  </td>
    26922692               </tr>
    … …  
    30933093      <p id="rfc.section.A.2.p.7">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
    30943094      </p>
    3095       <p id="rfc.section.A.2.p.8">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>)
     3095      <p id="rfc.section.A.2.p.8">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">4</a>)
    30963096      </p>
    30973097      <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
    3098          disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>)
    3099       </p>
    3100       <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.3</a>)
     3098         disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>)
     3099      </p>
     3100      <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;4.3</a>)
    31013101      </p>
    31023102      <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    … …  
    36383638         <ul class="ind">
    36393639            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    3640                   <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1</a></li>
     3640                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">5.1</a></li>
    36413641                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.3</b></a></li>
    36423642                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
    3643                   <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">4.1</a></li>
    3644                   <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1</a></li>
     3643                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">5.1</a></li>
     3644                  <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">5.1</a></li>
    36453645               </ul>
    36463646            </li>
    … …  
    36533653                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.4</b></a></li>
    36543654                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.3</b></a></li>
    3655                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.1</a></li>
     3655                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
    36563656                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    36573657                  <li>Coding Format&nbsp;&nbsp;
    36583658                     <ul>
    3659                         <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1</a></li>
    3660                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.2.1</a></li>
    3661                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.2.2</a></li>
    3662                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.12">5.2.3</a></li>
     3659                        <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.8">4.1</a></li>
     3660                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
     3661                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.11">4.2.2</a></li>
     3662                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.12">4.2.3</a></li>
    36633663                     </ul>
    36643664                  </li>
    3665                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.2.1</a></li>
     3665                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    36663666                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3667                   <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>
     3667                  <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">4.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>
    36683668                  <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>
    36693669               </ul>
    36703670            </li>
    36713671            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3672                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.2.2</a></li>
     3672                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">4.2.2</a></li>
    36733673                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.3</b></a></li>
    36743674               </ul>
    36753675            </li>
    36763676            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    3677                   <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>4.3</b></a></li>
     3677                  <li>effective request URI&nbsp;&nbsp;<a href="#rfc.iref.e.1"><b>5.3</b></a></li>
    36783678               </ul>
    36793679            </li>
    … …  
    36843684                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.7</b></a></li>
    36853685                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    3686                         <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5</b></a></li>
     3686                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>4</b></a></li>
    36873687                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
    36883688                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
    3689                         <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1</b></a></li>
    3690                         <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.1</b></a></li>
    3691                         <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1</b></a></li>
    3692                         <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1</b></a></li>
    3693                         <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.1</b></a></li>
    3694                         <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1</b></a></li>
    3695                         <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1</b></a></li>
     3689                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>4.1</b></a></li>
     3690                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>4.1</b></a></li>
     3691                        <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>4.1</b></a></li>
     3692                        <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>4.1</b></a></li>
     3693                        <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>4.1</b></a></li>
     3694                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>4.1</b></a></li>
     3695                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a></li>
    36963696                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
    36973697                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>8.1</b></a></li>
    … …  
    37023702                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.4</b></a></li>
    37033703                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    3704                         <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5</b></a></li>
    3705                         <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5</b></a></li>
     3704                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>4</b></a></li>
     3705                        <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>4</b></a></li>
    37063706                        <li>DIGIT&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>1.2</b></a></li>
    37073707                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    … …  
    37183718                        <li><tt>HTTP-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.6</b></a></li>
    37193719                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7.2</b></a></li>
    3720                         <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1</b></a></li>
     3720                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>4.1</b></a></li>
    37213721                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    37223722                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>3.3</b></a></li>
    … …  
    37323732                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>8.4</b></a></li>
    37333733                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
    3734                         <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.1</b></a></li>
     3734                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    37353735                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    37363736                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.2.4</b></a></li>
    37373737                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
    3738                         <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.1</b></a></li>
     3738                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.1</b></a></li>
    37393739                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
    3740                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>5.4.1</b></a></li>
     3740                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.4.1</b></a></li>
    37413741                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li>
    37423742                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>8.4</b></a></li>
    … …  
    37503750                        <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li>
    37513751                        <li><tt>status-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.2</b></a></li>
    3752                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>5.4</b></a></li>
     3752                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.4</b></a></li>
    37533753                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.4</b></a></li>
    3754                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>5.4</b></a></li>
    3755                         <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>5.4</b></a></li>
    3756                         <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>5.4</b></a></li>
     3754                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>4.4</b></a></li>
     3755                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.4</b></a></li>
     3756                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>4.4</b></a></li>
    37573757                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.4</b></a></li>
    3758                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.5</b></a></li>
    3759                         <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>5.1</b></a></li>
    3760                         <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5</b></a></li>
     3758                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>4.5</b></a></li>
     3759                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>4.1</b></a></li>
     3760                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>4</b></a></li>
    37613761                        <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>3.3.1</b></a></li>
    3762                         <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5</b></a></li>
    3763                         <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5</b></a></li>
     3762                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
     3763                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    37643764                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>8.3</b></a></li>
    37653765                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37663766                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
    3767                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5</b></a></li>
     3767                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>4</b></a></li>
    37683768                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    37693769                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>8.4</b></a></li>
    … …  
    37713771                     </ul>
    37723772                  </li>
    3773                   <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.73">5.2.3</a></li>
     3773                  <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.73">4.2.3</a></li>
    37743774               </ul>
    37753775            </li>
    … …  
    37783778                  <li>Header Fields&nbsp;&nbsp;
    37793779                     <ul>
    3780                         <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>
     3780                        <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">4.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>
    37813781                        <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>
    3782                         <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>
    3783                         <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>
    3784                         <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>
    3785                         <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>
     3782                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.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>
     3783                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3784                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3785                        <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">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    37863786                        <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>
    37873787                        <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>
    … …  
    37903790                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    37913791                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3792                   <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>
     3792                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.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>
    37933793                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    37943794                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38233823            </li>
    38243824            <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul>
    3825                   <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">4.1</a></li>
     3825                  <li>origin form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.o.3">5.1</a></li>
    38263826                  <li>origin server&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>2.1</b></a></li>
    38273827                  <li>outbound&nbsp;&nbsp;<a href="#rfc.iref.o.2"><b>2.3</b></a></li>
    … …  
    38303830            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38313831                  <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>
    3832                   <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>
     3832                  <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">5.1</a>, <a href="#rfc.xref.Part2.9">5.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>
    38333833                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    38343834                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    38353835                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    38363836                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a></li>
    3837                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
    3838                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
     3837                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">5.1</a></li>
     3838                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
    38393839                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a></li>
    38403840                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    … …  
    38463846                     </ul>
    38473847                  </li>
    3848                   <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>
    3849                         <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>
    3850                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">5.4.1</a></li>
     3848                  <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">4.3</a>, <a href="#rfc.xref.Part3.4">4.4.1</a>, <a href="#rfc.xref.Part3.5">6.1.3.2</a>, <a href="#Part3"><b>12.1</b></a><ul>
     3849                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a></li>
     3850                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">4.4.1</a></li>
    38513851                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    38523852                     </ul>
    … …  
    38703870                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li>
    38713871                  <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>
    3872                   <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>
    3873                   <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>
    3874                   <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>
     3872                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
     3873                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
     3874                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    38753875                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
    38763876                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">3.3.1</a></li>
    … …  
    38963896                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li>
    38973897                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
    3898                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    3899                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">4.1</a></li>
     3898                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">5.1</a>, <a href="#rfc.xref.RFC3986.20">5.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
     3899                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.1</a></li>
    39003900                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    39013901                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.15">2.7.1</a></li>
    … …  
    39073907                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.5">2.7</a></li>
    39083908                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.7">2.7</a></li>
    3909                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">4.3</a></li>
     3909                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.3</a></li>
    39103910                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.16">2.7.3</a></li>
    39113911                     </ul>
    … …  
    39153915                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
    39163916                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li>
    3917                   <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>
    3918                         <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>
     3917                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
     3918                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a></li>
    39193919                     </ul>
    39203920                  </li>
    … …  
    39383938            </li>
    39393939            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3940                   <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.5"><b>4.3</b></a></li>
    3941                   <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>
     3940                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.3</b></a></li>
     3941                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
    39423942                  <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>
    3943                   <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>
    3944                   <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>
     3943                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3944                  <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">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    39453945                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    39463946                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
Note: See TracChangeset for help on using the changeset viewer.