Changeset 1574


Ignore:
Timestamp:
Mar 9, 2012, 11:18:43 PM (7 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1572 r1574  
    19191919</section>
    19201920
    1921 <section title="Message Routing" anchor="message.routing">
    1922 <t>
    1923    In most cases, the user agent is provided a URI reference
    1924    from which it determines an absolute URI for identifying the target
    1925    resource.  When a request to the resource is initiated, all or part
    1926    of that URI is used to construct the HTTP request-target.
    1927 </t>
    1928 
    1929 <section title="Types of Request Target" anchor="request-target-types">
    1930 <t>
    1931    The proper format choice of the four options available to request-target
    1932    depends on the method being requested and if the request is being made to
    1933    a proxy.
    1934 </t>   
    1935 <t anchor="origin-form"><iref item="origin form (of request-target)"/>
    1936    The most common form of request-target is that used when making
    1937    a request to an origin server ("origin form") to access a resource
    1938    identified by an "http" (<xref target="http.uri"/>) or
    1939    "https" (<xref target="https.uri"/>) URI.
    1940    In this case, the absolute path and query components of the URI
    1941    &MUST; be transmitted as the request-target and the authority component
    1942    (excluding any userinfo) &MUST; be transmitted in a Host header field.
    1943    For example, a client wishing to retrieve a representation of the resource
    1944    identified as
    1945 </t>
    1946 <figure><artwork x:indent-with="  ">
    1947 http://www.example.org/where?q=now
    1948 </artwork></figure>
    1949 <t>
    1950    directly from the origin server would open (or reuse) a TCP connection
    1951    to port 80 of the host "www.example.org" and send the lines:
    1952 </t>
    1953 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1954 GET /where?q=now HTTP/1.1
    1955 Host: www.example.org
    1956 </artwork></figure>
    1957 <t>
    1958    followed by the remainder of the request. Note that the origin form
    1959    of request-target always starts with an absolute path. If the target
    1960    resource's URI path is empty, then an absolute path of "/" &MUST; be
    1961    provided in the request-target.
    1962 </t>
    1963 <t>
    1964    If the request-target is percent-encoded
    1965    (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
    1966    &MUST; decode the request-target in order to
    1967    properly interpret the request. Servers &SHOULD; respond to invalid
    1968    request-targets with an appropriate status code.
    1969 </t>
    1970 <t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
    1971    The "absolute-URI" form of request-target is &REQUIRED; when the request
    1972    is being made to a proxy.  The proxy is requested to either forward the
    1973    request or service it from a valid cache, and then return the response.
    1974    Note that the proxy &MAY; forward the request on to another proxy or
    1975    directly to the server specified by the absolute-URI.
    1976    In order to avoid request loops, a proxy that forwards requests to other
    1977    proxies &MUST; be able to recognize and exclude all of its own server
    1978    names, including any aliases, local variations, or literal IP addresses.
    1979    An example request-line would be:
    1980 </t>
    1981 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1982 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1983 </artwork></figure>
    1984 <t>
    1985    To allow for transition to absolute-URIs in all requests in future
    1986    versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
    1987    form in requests, even though HTTP/1.1 clients will only generate
    1988    them in requests to proxies.
    1989 </t>
    1990 <t>
    1991    If a proxy receives a host name that is not a fully qualified domain
    1992    name, it &MAY; add its domain to the host name it received. If a proxy
    1993    receives a fully qualified domain name, the proxy &MUST-NOT; change
    1994    the host name.
    1995 </t>
    1996 <t anchor="authority-form"><iref item="authority form (of request-target)"/>
    1997    The "authority form" of request-target, which &MUST-NOT; be used
    1998    with any request method other than CONNECT, is used to establish a
    1999    tunnel through one or more proxies (&CONNECT;).  For example,
    2000 </t>
    2001 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2002 CONNECT www.example.com:80 HTTP/1.1
    2003 </artwork></figure>
    2004 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
    2005    The asterisk ("*") form of request-target, which &MUST-NOT; be used
    2006    with any request method other than OPTIONS, means that the request
    2007    applies to the server as a whole (the listening process) rather than
    2008    to a specific named resource at that server.  For example,
    2009 </t>
    2010 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2011 OPTIONS * HTTP/1.1
    2012 </artwork></figure>
    2013 <t>
    2014    If a proxy receives an OPTIONS request with an absolute-URI form of
    2015    request-target in which the URI has an empty path and no query component,
    2016    then the last proxy on the request chain &MUST; use a request-target
    2017    of "*" when it forwards the request to the indicated origin server.
    2018 </t>
    2019 <figure><preamble>   
    2020    For example, the request
    2021 </preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2022 OPTIONS http://www.example.org:8001 HTTP/1.1
    2023 </artwork></figure>
    2024 <figure><preamble>   
    2025   would be forwarded by the final proxy as
    2026 </preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2027 OPTIONS * HTTP/1.1
    2028 Host: www.example.org:8001
    2029 </artwork>
    2030 <postamble>
    2031    after connecting to port 8001 of host "www.example.org".
    2032 </postamble>
    2033 </figure>
    2034 <t>
    2035    A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    2036    parts of the received request-target when forwarding it to the next inbound
    2037    server, except as noted above to replace a null path-absolute with "/" or
    2038    "*".
    2039 </t>
    2040 </section>
    2041 
    2042 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
    2043 <t>
    2044    The exact resource identified by an Internet request is determined by
    2045    examining both the request-target and the Host header field.
    2046 </t>
    2047 <t>
    2048    An origin server that does not allow resources to differ by the
    2049    requested host &MAY; ignore the Host header field value when
    2050    determining the resource identified by an HTTP/1.1 request. (But see
    2051    <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
    2052    for other requirements on Host support in HTTP/1.1.)
    2053 </t>
    2054 <t>
    2055    An origin server that does differentiate resources based on the host
    2056    requested (sometimes referred to as virtual hosts or vanity host
    2057    names) &MUST; use the following rules for determining the requested
    2058    resource on an HTTP/1.1 request:
    2059   <list style="numbers">
    2060     <t>If request-target is an absolute-URI, the host is part of the
    2061      request-target. Any Host header field value in the request &MUST; be
    2062      ignored.</t>
    2063     <t>If the request-target is not an absolute-URI, and the request includes
    2064      a Host header field, the host is determined by the Host header
    2065      field value.</t>
    2066     <t>If the host as determined by rule 1 or 2 is not a valid host on
    2067      the server, the response &MUST; be a 400 (Bad Request) error message.</t>
    2068   </list>
    2069 </t>
    2070 <t>
    2071    Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
    2072    attempt to use heuristics (e.g., examination of the URI path for
    2073    something unique to a particular host) in order to determine what
    2074    exact resource is being requested.
    2075 </t>
    2076 </section>
    2077 
    2078 <section title="Effective Request URI" anchor="effective.request.uri">
    2079   <iref primary="true" item="effective request URI"/>
    2080   <iref primary="true" item="target resource"/>
    2081 <t>
    2082    HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    2083    for the target resource; instead, the URI needs to be inferred from the
    2084    request-target, Host header field, and connection context. The result of
    2085    this process is called the "effective request URI".  The "target resource"
    2086    is the resource identified by the effective request URI.
    2087 </t>
    2088 <t>
    2089    If the request-target is an absolute-URI, then the effective request URI is
    2090    the request-target.
    2091 </t>
    2092 <t>
    2093    If the request-target uses the origin form or the asterisk form,
    2094    and the Host header field is present, then the effective request URI is
    2095    constructed by concatenating
    2096 </t>
    2097 <t>
    2098   <list style="symbols">
    2099     <t>
    2100       the scheme name: "http" if the request was received over an insecure
    2101       TCP connection, or "https" when received over a SSL/TLS-secured TCP
    2102       connection,
    2103     </t>
    2104     <t>
    2105       the octet sequence "://",
    2106     </t>
    2107     <t>
    2108       the authority component, as specified in the Host header field
    2109       (<xref target="header.host"/>), and
    2110     </t>
    2111     <t>
    2112       the request-target obtained from the request-line, unless the
    2113       request-target is just the asterisk "*".
    2114     </t>
    2115   </list>
    2116 </t>
    2117 <t>
    2118    If the request-target uses the origin form or the asterisk form,
    2119    and the Host header field is not present, then the effective request URI is
    2120    undefined.
    2121 </t>
    2122 <t>
    2123    Otherwise, when request-target uses the authority form, the effective
    2124    request URI is undefined.
    2125 </t>
    2126 <figure>
    2127 <preamble>
    2128    Example 1: the effective request URI for the message
    2129 </preamble>
    2130 <artwork type="example" x:indent-with="  ">
    2131 GET /pub/WWW/TheProject.html HTTP/1.1
    2132 Host: www.example.org:8080
    2133 </artwork>
    2134 <postamble>
    2135   (received over an insecure TCP connection) is "http", plus "://", plus the
    2136   authority component "www.example.org:8080", plus the request-target
    2137   "/pub/WWW/TheProject.html", thus
    2138   "http://www.example.org:8080/pub/WWW/TheProject.html".
    2139 </postamble>
    2140 </figure>
    2141 <figure>
    2142 <preamble>
    2143    Example 2: the effective request URI for the message
    2144 </preamble>
    2145 <artwork type="example" x:indent-with="  ">
    2146 OPTIONS * HTTP/1.1
    2147 Host: www.example.org
    2148 </artwork>
    2149 <postamble>
    2150   (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
    2151   authority component "www.example.org", thus "https://www.example.org".
    2152 </postamble>
    2153 </figure>
    2154 <t>
    2155    Effective request URIs are compared using the rules described in
    2156    <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    2157    be treated as equivalent to an absolute path of "/".
    2158 </t> 
    2159 </section>
    2160 
    2161 <section title="Associating a Response to a Request" anchor="associating.response.to.request">
    2162 <t>
    2163    HTTP does not include a request identifier for associating a given
    2164    request message with its corresponding one or more response messages.
    2165    Hence, it relies on the order of response arrival to correspond exactly
    2166    to the order in which requests are made on the same connection.
    2167    More than one response message per request only occurs when one or more
    2168    informational responses (1xx, see &status-1xx;) precede a final response
    2169    to the same request.
    2170 </t>
    2171 <t>
    2172    A client that uses persistent connections and sends more than one request
    2173    per connection &MUST; maintain a list of outstanding requests in the
    2174    order sent on that connection and &MUST; associate each received response
    2175    message to the highest ordered request that has not yet received a final
    2176    (non-1xx) response.
    2177 </t>
    2178 </section>
    2179 </section>
    2180 
    21811921<section title="Transfer Codings" anchor="transfer.codings">
    21821922  <x:anchor-alias value="transfer-coding"/>
     
    25492289    <t>Trailer</t>
    25502290  </list>
     2291</t>
     2292</section>
     2293</section>
     2294
     2295<section title="Message Routing" anchor="message.routing">
     2296<t>
     2297   In most cases, the user agent is provided a URI reference
     2298   from which it determines an absolute URI for identifying the target
     2299   resource.  When a request to the resource is initiated, all or part
     2300   of that URI is used to construct the HTTP request-target.
     2301</t>
     2302
     2303<section title="Types of Request Target" anchor="request-target-types">
     2304<t>
     2305   The proper format choice of the four options available to request-target
     2306   depends on the method being requested and if the request is being made to
     2307   a proxy.
     2308</t>   
     2309<t anchor="origin-form"><iref item="origin form (of request-target)"/>
     2310   The most common form of request-target is that used when making
     2311   a request to an origin server ("origin form") to access a resource
     2312   identified by an "http" (<xref target="http.uri"/>) or
     2313   "https" (<xref target="https.uri"/>) URI.
     2314   In this case, the absolute path and query components of the URI
     2315   &MUST; be transmitted as the request-target and the authority component
     2316   (excluding any userinfo) &MUST; be transmitted in a Host header field.
     2317   For example, a client wishing to retrieve a representation of the resource
     2318   identified as
     2319</t>
     2320<figure><artwork x:indent-with="  ">
     2321http://www.example.org/where?q=now
     2322</artwork></figure>
     2323<t>
     2324   directly from the origin server would open (or reuse) a TCP connection
     2325   to port 80 of the host "www.example.org" and send the lines:
     2326</t>
     2327<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2328GET /where?q=now HTTP/1.1
     2329Host: www.example.org
     2330</artwork></figure>
     2331<t>
     2332   followed by the remainder of the request. Note that the origin form
     2333   of request-target always starts with an absolute path. If the target
     2334   resource's URI path is empty, then an absolute path of "/" &MUST; be
     2335   provided in the request-target.
     2336</t>
     2337<t>
     2338   If the request-target is percent-encoded
     2339   (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
     2340   &MUST; decode the request-target in order to
     2341   properly interpret the request. Servers &SHOULD; respond to invalid
     2342   request-targets with an appropriate status code.
     2343</t>
     2344<t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
     2345   The "absolute-URI" form of request-target is &REQUIRED; when the request
     2346   is being made to a proxy.  The proxy is requested to either forward the
     2347   request or service it from a valid cache, and then return the response.
     2348   Note that the proxy &MAY; forward the request on to another proxy or
     2349   directly to the server specified by the absolute-URI.
     2350   In order to avoid request loops, a proxy that forwards requests to other
     2351   proxies &MUST; be able to recognize and exclude all of its own server
     2352   names, including any aliases, local variations, or literal IP addresses.
     2353   An example request-line would be:
     2354</t>
     2355<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2356GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     2357</artwork></figure>
     2358<t>
     2359   To allow for transition to absolute-URIs in all requests in future
     2360   versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
     2361   form in requests, even though HTTP/1.1 clients will only generate
     2362   them in requests to proxies.
     2363</t>
     2364<t>
     2365   If a proxy receives a host name that is not a fully qualified domain
     2366   name, it &MAY; add its domain to the host name it received. If a proxy
     2367   receives a fully qualified domain name, the proxy &MUST-NOT; change
     2368   the host name.
     2369</t>
     2370<t anchor="authority-form"><iref item="authority form (of request-target)"/>
     2371   The "authority form" of request-target, which &MUST-NOT; be used
     2372   with any request method other than CONNECT, is used to establish a
     2373   tunnel through one or more proxies (&CONNECT;).  For example,
     2374</t>
     2375<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2376CONNECT www.example.com:80 HTTP/1.1
     2377</artwork></figure>
     2378<t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
     2379   The asterisk ("*") form of request-target, which &MUST-NOT; be used
     2380   with any request method other than OPTIONS, means that the request
     2381   applies to the server as a whole (the listening process) rather than
     2382   to a specific named resource at that server.  For example,
     2383</t>
     2384<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2385OPTIONS * HTTP/1.1
     2386</artwork></figure>
     2387<t>
     2388   If a proxy receives an OPTIONS request with an absolute-URI form of
     2389   request-target in which the URI has an empty path and no query component,
     2390   then the last proxy on the request chain &MUST; use a request-target
     2391   of "*" when it forwards the request to the indicated origin server.
     2392</t>
     2393<figure><preamble>   
     2394   For example, the request
     2395</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2396OPTIONS http://www.example.org:8001 HTTP/1.1
     2397</artwork></figure>
     2398<figure><preamble>   
     2399  would be forwarded by the final proxy as
     2400</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2401OPTIONS * HTTP/1.1
     2402Host: www.example.org:8001
     2403</artwork>
     2404<postamble>
     2405   after connecting to port 8001 of host "www.example.org".
     2406</postamble>
     2407</figure>
     2408<t>
     2409   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
     2410   parts of the received request-target when forwarding it to the next inbound
     2411   server, except as noted above to replace a null path-absolute with "/" or
     2412   "*".
     2413</t>
     2414</section>
     2415
     2416<section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
     2417<t>
     2418   The exact resource identified by an Internet request is determined by
     2419   examining both the request-target and the Host header field.
     2420</t>
     2421<t>
     2422   An origin server that does not allow resources to differ by the
     2423   requested host &MAY; ignore the Host header field value when
     2424   determining the resource identified by an HTTP/1.1 request. (But see
     2425   <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
     2426   for other requirements on Host support in HTTP/1.1.)
     2427</t>
     2428<t>
     2429   An origin server that does differentiate resources based on the host
     2430   requested (sometimes referred to as virtual hosts or vanity host
     2431   names) &MUST; use the following rules for determining the requested
     2432   resource on an HTTP/1.1 request:
     2433  <list style="numbers">
     2434    <t>If request-target is an absolute-URI, the host is part of the
     2435     request-target. Any Host header field value in the request &MUST; be
     2436     ignored.</t>
     2437    <t>If the request-target is not an absolute-URI, and the request includes
     2438     a Host header field, the host is determined by the Host header
     2439     field value.</t>
     2440    <t>If the host as determined by rule 1 or 2 is not a valid host on
     2441     the server, the response &MUST; be a 400 (Bad Request) error message.</t>
     2442  </list>
     2443</t>
     2444<t>
     2445   Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
     2446   attempt to use heuristics (e.g., examination of the URI path for
     2447   something unique to a particular host) in order to determine what
     2448   exact resource is being requested.
     2449</t>
     2450</section>
     2451
     2452<section title="Effective Request URI" anchor="effective.request.uri">
     2453  <iref primary="true" item="effective request URI"/>
     2454  <iref primary="true" item="target resource"/>
     2455<t>
     2456   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
     2457   for the target resource; instead, the URI needs to be inferred from the
     2458   request-target, Host header field, and connection context. The result of
     2459   this process is called the "effective request URI".  The "target resource"
     2460   is the resource identified by the effective request URI.
     2461</t>
     2462<t>
     2463   If the request-target is an absolute-URI, then the effective request URI is
     2464   the request-target.
     2465</t>
     2466<t>
     2467   If the request-target uses the origin form or the asterisk form,
     2468   and the Host header field is present, then the effective request URI is
     2469   constructed by concatenating
     2470</t>
     2471<t>
     2472  <list style="symbols">
     2473    <t>
     2474      the scheme name: "http" if the request was received over an insecure
     2475      TCP connection, or "https" when received over a SSL/TLS-secured TCP
     2476      connection,
     2477    </t>
     2478    <t>
     2479      the octet sequence "://",
     2480    </t>
     2481    <t>
     2482      the authority component, as specified in the Host header field
     2483      (<xref target="header.host"/>), and
     2484    </t>
     2485    <t>
     2486      the request-target obtained from the request-line, unless the
     2487      request-target is just the asterisk "*".
     2488    </t>
     2489  </list>
     2490</t>
     2491<t>
     2492   If the request-target uses the origin form or the asterisk form,
     2493   and the Host header field is not present, then the effective request URI is
     2494   undefined.
     2495</t>
     2496<t>
     2497   Otherwise, when request-target uses the authority form, the effective
     2498   request URI is undefined.
     2499</t>
     2500<figure>
     2501<preamble>
     2502   Example 1: the effective request URI for the message
     2503</preamble>
     2504<artwork type="example" x:indent-with="  ">
     2505GET /pub/WWW/TheProject.html HTTP/1.1
     2506Host: www.example.org:8080
     2507</artwork>
     2508<postamble>
     2509  (received over an insecure TCP connection) is "http", plus "://", plus the
     2510  authority component "www.example.org:8080", plus the request-target
     2511  "/pub/WWW/TheProject.html", thus
     2512  "http://www.example.org:8080/pub/WWW/TheProject.html".
     2513</postamble>
     2514</figure>
     2515<figure>
     2516<preamble>
     2517   Example 2: the effective request URI for the message
     2518</preamble>
     2519<artwork type="example" x:indent-with="  ">
     2520OPTIONS * HTTP/1.1
     2521Host: www.example.org
     2522</artwork>
     2523<postamble>
     2524  (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
     2525  authority component "www.example.org", thus "https://www.example.org".
     2526</postamble>
     2527</figure>
     2528<t>
     2529   Effective request URIs are compared using the rules described in
     2530   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
     2531   be treated as equivalent to an absolute path of "/".
     2532</t> 
     2533</section>
     2534
     2535<section title="Associating a Response to a Request" anchor="associating.response.to.request">
     2536<t>
     2537   HTTP does not include a request identifier for associating a given
     2538   request message with its corresponding one or more response messages.
     2539   Hence, it relies on the order of response arrival to correspond exactly
     2540   to the order in which requests are made on the same connection.
     2541   More than one response message per request only occurs when one or more
     2542   informational responses (1xx, see &status-1xx;) precede a final response
     2543   to the same request.
     2544</t>
     2545<t>
     2546   A client that uses persistent connections and sends more than one request
     2547   per connection &MUST; maintain a list of outstanding requests in the
     2548   order sent on that connection and &MUST; associate each received response
     2549   message to the highest ordered request that has not yet received a final
     2550   (non-1xx) response.
    25512551</t>
    25522552</section>
Note: See TracChangeset for help on using the changeset viewer.