Changeset 1574 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 10/03/12 07:18:43 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1572 r1574 485 485 <link rel="Chapter" title="2 Architecture" href="#rfc.section.2"> 486 486 <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"> 489 489 <link rel="Chapter" title="6 Connections" href="#rfc.section.6"> 490 490 <link rel="Chapter" title="7 Miscellaneous notes that might disappear" href="#rfc.section.7"> … … 698 698 </ul> 699 699 </li> 700 <li>4. <a href="#message.routing">Message Routing</a><ul> 701 <li>4.1 <a href="#request-target-types">Types of Request Target</a></li> 702 <li>4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 703 <li>4.3 <a href="#effective.request.uri">Effective Request URI</a></li> 704 <li>4.4 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 705 </ul> 706 </li> 707 <li>5. <a href="#transfer.codings">Transfer Codings</a><ul> 708 <li>5.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 709 <li>5.2 <a href="#compression.codings">Compression Codings</a><ul> 710 <li>5.2.1 <a href="#compress.coding">Compress Coding</a></li> 711 <li>5.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 712 <li>5.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 700 <li>4. <a href="#transfer.codings">Transfer Codings</a><ul> 701 <li>4.1 <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 702 <li>4.2 <a href="#compression.codings">Compression Codings</a><ul> 703 <li>4.2.1 <a href="#compress.coding">Compress Coding</a></li> 704 <li>4.2.2 <a href="#deflate.coding">Deflate Coding</a></li> 705 <li>4.2.3 <a href="#gzip.coding">Gzip Coding</a></li> 713 706 </ul> 714 707 </li> 715 <li> 5.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li>716 <li> 5.4 <a href="#header.te">TE</a><ul>717 <li> 5.4.1 <a href="#quality.values">Quality Values</a></li>708 <li>4.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 709 <li>4.4 <a href="#header.te">TE</a><ul> 710 <li>4.4.1 <a href="#quality.values">Quality Values</a></li> 718 711 </ul> 719 712 </li> 720 <li>5.5 <a href="#header.trailer">Trailer</a></li> 713 <li>4.5 <a href="#header.trailer">Trailer</a></li> 714 </ul> 715 </li> 716 <li>5. <a href="#message.routing">Message Routing</a><ul> 717 <li>5.1 <a href="#request-target-types">Types of Request Target</a></li> 718 <li>5.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 719 <li>5.3 <a href="#effective.request.uri">Effective Request URI</a></li> 720 <li>5.4 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 721 721 </ul> 722 722 </li> … … 1154 1154 </p> 1155 1155 <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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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. 1157 1157 </p> 1158 1158 <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 … … 1252 1252 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="request-target" href="#request-target">request-target</a></h4> 1253 1253 <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 4.1</a>.1254 described in <a href="#request-target-types" title="Types of Request Target">Section 5.1</a>. 1255 1255 </p> 1256 1256 <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> = "*" … … 1377 1377 <div id="rule.token.separators"> 1378 1378 <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 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 4</a>). 1380 1380 </p> 1381 1381 </div> … … 1471 1471 <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 1472 1472 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 5</a>.1473 in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>. 1474 1474 </p> 1475 1475 <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> … … 1479 1479 applied for transport efficiency or security from those that are characteristics of the target resource. 1480 1480 </p> 1481 <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 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 size1481 <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 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 1482 1482 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 1483 1483 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. … … 1546 1546 </li> 1547 1547 <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 5.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding1548 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding 1549 1549 indicates the data is complete. 1550 1550 </p> … … 1630 1630 above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response. 1631 1631 </p> 1632 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <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> <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 2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section 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> <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 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> <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 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 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> <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> <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> <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 1762 1634 to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the 1763 1635 transfer-coding is a property of the message rather than a property of the representation that is being transferred. 1764 1636 </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 5.1</a>1766 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 5.2.1</a>1767 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 5.2.2</a>1768 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 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 4.1</a> 1638 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 4.2.1</a> 1639 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a> 1640 / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section 4.2.3</a> 1769 1641 / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1770 1642 <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> ) 1771 1643 </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> 1773 1645 </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> 1775 1647 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1776 1648 <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 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 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 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 3.3.1</a>). 1778 1650 </p> 1779 1651 <div id="rfc.iref.c.7"></div> 1780 1652 <div id="rfc.iref.c.8"></div> 1781 <h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> <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 size1653 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <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 1783 1655 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 1784 1656 for the recipient to verify that it has received the full message. 1785 1657 </p> 1786 <div id="rfc.figure.u.4 9"></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> 1787 1659 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1788 1660 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1803 1675 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1804 1676 <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 ended1677 </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 1806 1678 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1807 1679 </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 field1809 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 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 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: 1812 1684 </p> 1813 1685 <ol> 1814 1686 <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 5.4</a>; or,1687 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.4</a>; or, 1816 1688 </li> 1817 1689 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable … … 1821 1693 </li> 1822 1694 </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 and1695 <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 1824 1696 forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly 1825 1697 infinite buffer on the proxy. 1826 1698 </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 := 01699 <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 1829 1701 read chunk-size, chunk-ext (if any) and CRLF 1830 1702 while (chunk-size > 0) { … … 1841 1713 Content-Length := length 1842 1714 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> <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> <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"> 1850 1722 <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. 1851 1723 Their use here is representative of historical practice, not good design. 1852 1724 </p> 1853 1725 </div> 1854 <div class="note" id="rfc.section. 5.2.p.3">1726 <div class="note" id="rfc.section.4.2.p.3"> 1855 1727 <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. 1856 1728 </p> … … 1858 1730 <div id="rfc.iref.c.9"></div> 1859 1731 <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> <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-Welch1732 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <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 1862 1734 coding (LZW). 1863 1735 </p> 1864 1736 <div id="rfc.iref.d.2"></div> 1865 1737 <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> <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> <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"> 1870 1742 <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper. 1871 1743 </p> … … 1873 1745 <div id="rfc.iref.g.73"></div> 1874 1746 <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> <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> <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> <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> <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: 1881 1753 </p> 1882 1754 <ul> … … 1885 1757 <li>Pointer to specification text</li> 1886 1758 </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 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 <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.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 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 <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 1764 </p> 1765 <div id="rfc.iref.t.5"></div> 1894 1766 <div id="rfc.iref.h.8"></div> 1895 <h2 id="rfc.section. 5.4"><a href="#rfc.section.5.4">5.4</a> <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 whether1767 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <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 1897 1769 or not it is willing to accept trailer fields in a chunked transfer-coding. 1898 1770 </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 optional1900 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 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 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> 1903 1775 <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> ] ) 1904 1776 <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> ) 1905 1777 <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 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: deflate1778 </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 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 1911 1783 TE: 1912 1784 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 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 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> 1916 1788 <ol> 1917 1789 <li> … … 1927 1799 <li> 1928 1800 <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 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 4.4.1</a>, a qvalue of 0 means "not acceptable".) 1930 1802 </p> 1931 1803 </li> … … 1936 1808 </li> 1937 1809 </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 with1810 <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 1939 1811 no transfer-coding is always acceptable. 1940 1812 </p> 1941 <h3 id="rfc.section. 5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a> <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 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 weight1813 <h3 id="rfc.section.4.4.1"><a href="#rfc.section.4.4.1">4.4.1</a> <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 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 1943 1815 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 1944 1816 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. 1945 1817 </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> ] ) 1947 1819 / ( "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"> 1949 1821 <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality. 1950 1822 </p> 1951 1823 </div> 1952 <div id="rfc.iref.t. 7"></div>1824 <div id="rfc.iref.t.6"></div> 1953 1825 <div id="rfc.iref.h.9"></div> 1954 <h2 id="rfc.section. 5.5"><a href="#rfc.section.5.5">5.5</a> <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 with1826 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <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 1956 1828 chunked transfer-coding. 1957 1829 </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 recipient1830 <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 1960 1832 to know which header fields to expect in the trailer. 1961 1833 </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 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 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: 1965 1837 </p> 1966 1838 <ul> … … 1969 1841 <li>Trailer</li> 1970 1842 </ul> 1843 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <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> <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 2.7.1</a>) or "https" (<a href="#https.uri" title="https URI scheme">Section 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 1862 Host: 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 1898 Host: 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> <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 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> <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 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 1951 Host: 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 1957 Host: 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 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> <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> 1971 1971 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1> 1972 1972 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> … … 2093 2093 </p> 2094 2094 </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 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 4</a>). 2096 2096 </p> 2097 2097 <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 2132 2132 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 2133 2133 <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 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 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. 2135 2135 </p> 2136 2136 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> … … 2238 2238 <tr> 2239 2239 <td class="left">TE</td> 2240 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 5.4</a></td>2240 <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 4.4</a></td> 2241 2241 </tr> 2242 2242 <tr> 2243 2243 <td class="left">Trailer</td> 2244 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 5.5</a></td>2244 <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 4.5</a></td> 2245 2245 </tr> 2246 2246 <tr> … … 2328 2328 message that contains more than one Host header field or a Host header field with an invalid field-value. 2329 2329 </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. 2331 2331 </p> 2332 2332 <div id="rfc.iref.u.5"></div> … … 2474 2474 <td class="left">http</td> 2475 2475 <td class="left">standard</td> 2476 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 5.4</a>2476 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section 4.4</a> 2477 2477 </td> 2478 2478 </tr> … … 2481 2481 <td class="left">http</td> 2482 2482 <td class="left">standard</td> 2483 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 5.5</a>2483 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 4.5</a> 2484 2484 </td> 2485 2485 </tr> … … 2651 2651 </dl> 2652 2652 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <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 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 4.3</a> of this document. 2654 2654 </p> 2655 2655 <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registrations below: … … 2669 2669 <td class="left">chunked</td> 2670 2670 <td class="left">Transfer in a series of chunks</td> 2671 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>2671 <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> 2672 2672 </td> 2673 2673 </tr> … … 2675 2675 <td class="left">compress</td> 2676 2676 <td class="left">UNIX "compress" program method</td> 2677 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 5.2.1</a>2677 <td class="left"> <a href="#compress.coding" title="Compress Coding">Section 4.2.1</a> 2678 2678 </td> 2679 2679 </tr> … … 2682 2682 <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>) 2683 2683 </td> 2684 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 5.2.2</a>2684 <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a> 2685 2685 </td> 2686 2686 </tr> … … 2688 2688 <td class="left">gzip</td> 2689 2689 <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 5.2.3</a>2690 <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section 4.2.3</a> 2691 2691 </td> 2692 2692 </tr> … … 3093 3093 <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 3.3</a>) 3094 3094 </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>) 3096 3096 </p> 3097 3097 <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 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 5.3</a>)3098 disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 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 4.3</a>) 3101 3101 </p> 3102 3102 <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. … … 3638 3638 <ul class="ind"> 3639 3639 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 3640 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2"> 4.1</a></li>3640 <li>absolute-URI form (of request-target) <a href="#rfc.iref.a.2">5.1</a></li> 3641 3641 <li>accelerator <a href="#rfc.iref.a.1"><b>2.3</b></a></li> 3642 3642 <li>application/http Media Type <a href="#rfc.iref.a.5"><b>9.3.2</b></a></li> 3643 <li>asterisk form (of request-target) <a href="#rfc.iref.a.4"> 4.1</a></li>3644 <li>authority form (of request-target) <a href="#rfc.iref.a.3"> 4.1</a></li>3643 <li>asterisk form (of request-target) <a href="#rfc.iref.a.4">5.1</a></li> 3644 <li>authority form (of request-target) <a href="#rfc.iref.a.3">5.1</a></li> 3645 3645 </ul> 3646 3646 </li> … … 3653 3653 <li>cacheable <a href="#rfc.iref.c.5"><b>2.4</b></a></li> 3654 3654 <li>captive portal <a href="#rfc.iref.c.3"><b>2.3</b></a></li> 3655 <li>chunked (Coding Format) <a href="#rfc.iref.c.7"> 5.1</a></li>3655 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">4.1</a></li> 3656 3656 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3657 3657 <li>Coding Format 3658 3658 <ul> 3659 <li>chunked <a href="#rfc.iref.c.8"> 5.1</a></li>3660 <li>compress <a href="#rfc.iref.c.10"> 5.2.1</a></li>3661 <li>deflate <a href="#rfc.iref.c.11"> 5.2.2</a></li>3662 <li>gzip <a href="#rfc.iref.c.12"> 5.2.3</a></li>3659 <li>chunked <a href="#rfc.iref.c.8">4.1</a></li> 3660 <li>compress <a href="#rfc.iref.c.10">4.2.1</a></li> 3661 <li>deflate <a href="#rfc.iref.c.11">4.2.2</a></li> 3662 <li>gzip <a href="#rfc.iref.c.12">4.2.3</a></li> 3663 3663 </ul> 3664 3664 </li> 3665 <li>compress (Coding Format) <a href="#rfc.iref.c.9"> 5.2.1</a></li>3665 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3666 3666 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3667 <li>Connection header field <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 <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> 3668 3668 <li>Content-Length header field <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> 3669 3669 </ul> 3670 3670 </li> 3671 3671 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3672 <li>deflate (Coding Format) <a href="#rfc.iref.d.2"> 5.2.2</a></li>3672 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">4.2.2</a></li> 3673 3673 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3674 3674 </ul> 3675 3675 </li> 3676 3676 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 3677 <li>effective request URI <a href="#rfc.iref.e.1"><b> 4.3</b></a></li>3677 <li>effective request URI <a href="#rfc.iref.e.1"><b>5.3</b></a></li> 3678 3678 </ul> 3679 3679 </li> … … 3684 3684 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3685 3685 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3686 <li><tt>attribute</tt> <a href="#rfc.iref.g.58"><b> 5</b></a></li>3686 <li><tt>attribute</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3687 3687 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3688 3688 <li><tt>BWS</tt> <a href="#rfc.iref.g.40"><b>3.2.1</b></a></li> 3689 <li><tt>chunk</tt> <a href="#rfc.iref.g.63"><b> 5.1</b></a></li>3690 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.69"><b> 5.1</b></a></li>3691 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.66"><b> 5.1</b></a></li>3692 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.67"><b> 5.1</b></a></li>3693 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.68"><b> 5.1</b></a></li>3694 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.64"><b> 5.1</b></a></li>3695 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b> 5.1</b></a></li>3689 <li><tt>chunk</tt> <a href="#rfc.iref.g.63"><b>4.1</b></a></li> 3690 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a></li> 3691 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.66"><b>4.1</b></a></li> 3692 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.67"><b>4.1</b></a></li> 3693 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.68"><b>4.1</b></a></li> 3694 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a></li> 3695 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3696 3696 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3697 3697 <li><tt>Connection</tt> <a href="#rfc.iref.g.80"><b>8.1</b></a></li> … … 3702 3702 <li><tt>ctext</tt> <a href="#rfc.iref.g.50"><b>3.2.4</b></a></li> 3703 3703 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3704 <li><tt>date2</tt> <a href="#rfc.iref.g.60"><b> 5</b></a></li>3705 <li><tt>date3</tt> <a href="#rfc.iref.g.61"><b> 5</b></a></li>3704 <li><tt>date2</tt> <a href="#rfc.iref.g.60"><b>4</b></a></li> 3705 <li><tt>date3</tt> <a href="#rfc.iref.g.61"><b>4</b></a></li> 3706 3706 <li>DIGIT <a href="#rfc.iref.g.5"><b>1.2</b></a></li> 3707 3707 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> … … 3718 3718 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3719 3719 <li><tt>https-URI</tt> <a href="#rfc.iref.g.24"><b>2.7.2</b></a></li> 3720 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.65"><b> 5.1</b></a></li>3720 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.65"><b>4.1</b></a></li> 3721 3721 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3722 3722 <li><tt>message-body</tt> <a href="#rfc.iref.g.52"><b>3.3</b></a></li> … … 3732 3732 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.89"><b>8.4</b></a></li> 3733 3733 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3734 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b> 5.1</b></a></li>3734 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> 3735 3735 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3736 3736 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.51"><b>3.2.4</b></a></li> 3737 3737 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.48"><b>3.2.4</b></a></li> 3738 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.71"><b> 5.1</b></a></li>3738 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3739 3739 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3740 <li><tt>qvalue</tt> <a href="#rfc.iref.g.78"><b> 5.4.1</b></a></li>3740 <li><tt>qvalue</tt> <a href="#rfc.iref.g.78"><b>4.4.1</b></a></li> 3741 3741 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2.2</b></a></li> 3742 3742 <li><tt>received-by</tt> <a href="#rfc.iref.g.88"><b>8.4</b></a></li> … … 3750 3750 <li><tt>status-code</tt> <a href="#rfc.iref.g.31"><b>3.1.2.1</b></a></li> 3751 3751 <li><tt>status-line</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3752 <li><tt>t-codings</tt> <a href="#rfc.iref.g.75"><b> 5.4</b></a></li>3752 <li><tt>t-codings</tt> <a href="#rfc.iref.g.75"><b>4.4</b></a></li> 3753 3753 <li><tt>tchar</tt> <a href="#rfc.iref.g.43"><b>3.2.4</b></a></li> 3754 <li><tt>TE</tt> <a href="#rfc.iref.g.74"><b> 5.4</b></a></li>3755 <li><tt>te-ext</tt> <a href="#rfc.iref.g.77"><b> 5.4</b></a></li>3756 <li><tt>te-params</tt> <a href="#rfc.iref.g.76"><b> 5.4</b></a></li>3754 <li><tt>TE</tt> <a href="#rfc.iref.g.74"><b>4.4</b></a></li> 3755 <li><tt>te-ext</tt> <a href="#rfc.iref.g.77"><b>4.4</b></a></li> 3756 <li><tt>te-params</tt> <a href="#rfc.iref.g.76"><b>4.4</b></a></li> 3757 3757 <li><tt>token</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3758 <li><tt>Trailer</tt> <a href="#rfc.iref.g.79"><b> 5.5</b></a></li>3759 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.70"><b> 5.1</b></a></li>3760 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.55"><b> 5</b></a></li>3758 <li><tt>Trailer</tt> <a href="#rfc.iref.g.79"><b>4.5</b></a></li> 3759 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> 3760 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.55"><b>4</b></a></li> 3761 3761 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.53"><b>3.3.1</b></a></li> 3762 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b> 5</b></a></li>3763 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b> 5</b></a></li>3762 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3763 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3764 3764 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.83"><b>8.3</b></a></li> 3765 3765 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3766 3766 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3767 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b> 5</b></a></li>3767 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3768 3768 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3769 3769 <li><tt>Via</tt> <a href="#rfc.iref.g.84"><b>8.4</b></a></li> … … 3771 3771 </ul> 3772 3772 </li> 3773 <li>gzip (Coding Format) <a href="#rfc.iref.g.73"> 5.2.3</a></li>3773 <li>gzip (Coding Format) <a href="#rfc.iref.g.73">4.2.3</a></li> 3774 3774 </ul> 3775 3775 </li> … … 3778 3778 <li>Header Fields 3779 3779 <ul> 3780 <li>Connection <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 <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> 3781 3781 <li>Content-Length <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 <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 <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 <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 <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 <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 <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 <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 <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> 3786 3786 <li>Upgrade <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> 3787 3787 <li>Via <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> … … 3790 3790 <li>header section <a href="#rfc.iref.h.3">3</a></li> 3791 3791 <li>headers <a href="#rfc.iref.h.4">3</a></li> 3792 <li>Host header field <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 <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> 3793 3793 <li>http URI scheme <a href="#rfc.iref.h.1"><b>2.7.1</b></a></li> 3794 3794 <li>https URI scheme <a href="#rfc.iref.h.2">2.7.2</a></li> … … 3823 3823 </li> 3824 3824 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3825 <li>origin form (of request-target) <a href="#rfc.iref.o.3"> 4.1</a></li>3825 <li>origin form (of request-target) <a href="#rfc.iref.o.3">5.1</a></li> 3826 3826 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3827 3827 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> … … 3830 3830 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3831 3831 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3832 <li><em>Part2</em> <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> <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> 3833 3833 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3834 3834 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3835 3835 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li> 3836 3836 <li><em>Section 6.1.2</em> <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> <a href="#rfc.xref.Part2.8"> 4.1</a></li>3838 <li><em>Section 7.1</em> <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> <a href="#rfc.xref.Part2.8">5.1</a></li> 3838 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.9">5.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> 3839 3839 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3840 3840 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> … … 3846 3846 </ul> 3847 3847 </li> 3848 <li><em>Part3</em> <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> <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> <a href="#rfc.xref.Part3.4"> 5.4.1</a></li>3848 <li><em>Part3</em> <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> <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> <a href="#rfc.xref.Part3.4">4.4.1</a></li> 3851 3851 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li> 3852 3852 </ul> … … 3870 3870 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>12.2</b></a></li> 3871 3871 <li><em>RFC1945</em> <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> <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> <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> <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> <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> <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> <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> 3875 3875 <li><em>RFC2045</em> <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> 3876 3876 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">3.3.1</a></li> … … 3896 3896 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>12.2</b></a></li> 3897 3897 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li> 3898 <li><em>RFC3986</em> <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> <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> <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> <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">5.1</a></li> 3900 3900 <li><em>Section 3.2</em> <a href="#rfc.xref.RFC3986.8">2.7</a></li> 3901 3901 <li><em>Section 3.2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.1</a></li> … … 3907 3907 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3986.5">2.7</a></li> 3908 3908 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.7">2.7</a></li> 3909 <li><em>Section 4.3</em> <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> <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.20">5.3</a></li> 3910 3910 <li><em>Section 6</em> <a href="#rfc.xref.RFC3986.16">2.7.3</a></li> 3911 3911 </ul> … … 3915 3915 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li> 3916 3916 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>12.2</b></a></li> 3917 <li><em>RFC5226</em> <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> <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> <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> <a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">8.3.1</a></li> 3919 3919 </ul> 3920 3920 </li> … … 3938 3938 </li> 3939 3939 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 3940 <li>target resource <a href="#rfc.iref.t. 5"><b>4.3</b></a></li>3941 <li>TE header field <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 <a href="#rfc.iref.t.7"><b>5.3</b></a></li> 3941 <li>TE header field <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> 3942 3942 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li> 3943 <li>Trailer header field <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 <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 <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 <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> 3945 3945 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3946 3946 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li>
Note: See TracChangeset
for help on using the changeset viewer.