Changeset 769 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 04/03/10 14:34:38 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r767 r769 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-03-0 3">406 <meta name="dct.issued" scheme="ISO8601" content="2010-03-04"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: September 4, 2010</td>437 <td class="left">Expires: September 5, 2010</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">March 3, 2010</td>490 <td class="right">March 4, 2010</td> 491 491 </tr> 492 492 </tbody> … … 520 520 <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. 521 521 </p> 522 <p>This Internet-Draft will expire in September 4, 2010.</p>522 <p>This Internet-Draft will expire in September 5, 2010.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 610 610 </ul> 611 611 </li> 612 <li class="tocline1">7.1.3 <a href="#persistent.proxy">Proxy Servers</a></li> 612 <li class="tocline1">7.1.3 <a href="#persistent.proxy">Proxy Servers</a><ul class="toc"> 613 <li class="tocline1">7.1.3.1 <a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li> 614 <li class="tocline1">7.1.3.2 <a href="#non-modifiable.headers">Non-modifiable Headers</a></li> 615 </ul> 616 </li> 613 617 <li class="tocline1">7.1.4 <a href="#persistent.practical">Practical Considerations</a></li> 614 618 </ul> … … 1714 1718 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients). 1715 1719 </p> 1720 <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a> <a id="end-to-end.and.hop-by-hop.headers" href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></h4> 1721 <p id="rfc.section.7.1.3.1.p.1"> <span class="comment" id="TODO-end-to-end">[<a href="#TODO-end-to-end" class="smpl">TODO-end-to-end</a>: Restored from <<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1">http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1</a>>. See also <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60</a>>. --jre]</span> 1722 </p> 1723 <p id="rfc.section.7.1.3.1.p.2">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p> 1724 <ul> 1725 <li>End-to-end headers, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses 1726 MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry. 1727 </li> 1728 <li>Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded 1729 by proxies. 1730 </li> 1731 </ul> 1732 <p id="rfc.section.7.1.3.1.p.3">The following HTTP/1.1 headers are hop-by-hop headers: </p> 1733 <ul> 1734 <li>Connection</li> 1735 <li>Keep-Alive</li> 1736 <li>Proxy-Authenticate</li> 1737 <li>Proxy-Authorization</li> 1738 <li>TE</li> 1739 <li>Trailer</li> 1740 <li>Transfer-Encoding</li> 1741 <li>Upgrade</li> 1742 </ul> 1743 <p id="rfc.section.7.1.3.1.p.4">All other headers defined by HTTP/1.1 are end-to-end headers.</p> 1744 <p id="rfc.section.7.1.3.1.p.5">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a>). 1745 </p> 1746 <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h4> 1747 <p id="rfc.section.7.1.3.2.p.1"> <span class="comment" id="TODO-non-mod-headers">[<a href="#TODO-non-mod-headers" class="smpl">TODO-non-mod-headers</a>: Restored from <<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2">http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2</a>>. See also <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60</a>>. --jre]</span> 1748 </p> 1749 <p id="rfc.section.7.1.3.2.p.2">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent 1750 proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that. 1751 </p> 1752 <p id="rfc.section.7.1.3.2.p.3">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 1753 </p> 1754 <ul> 1755 <li>Content-Location</li> 1756 <li>Content-MD5</li> 1757 <li>ETag</li> 1758 <li>Last-Modified</li> 1759 </ul> 1760 <p id="rfc.section.7.1.3.2.p.4">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response: 1761 </p> 1762 <ul> 1763 <li>Expires</li> 1764 </ul> 1765 <p id="rfc.section.7.1.3.2.p.5">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header in that response. 1766 </p> 1767 <p id="rfc.section.7.1.3.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: 1768 </p> 1769 <ul> 1770 <li>Content-Encoding</li> 1771 <li>Content-Range</li> 1772 <li>Content-Type</li> 1773 </ul> 1774 <p id="rfc.section.7.1.3.2.p.7">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1775 </p> 1776 <div class="note" id="rfc.section.7.1.3.2.p.8"> 1777 <p> <b>Warning:</b> Unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are 1778 introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 1779 </p> 1780 </div> 1781 <p id="rfc.section.7.1.3.2.p.9">The Content-Length field of a request or response is added or deleted according to the rules in <a href="#message.length" title="Message Length">Section 3.4</a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="p3-payload.html#entity.length" title="Entity Length">Section 3.2.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="#message.length" title="Message Length">Section 3.4</a>). 1782 </p> 1716 1783 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> 1717 1784 <p id="rfc.section.7.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers … … 1986 2053 TE: 1987 2054 TE: trailers, deflate;q=0.5 1988 </pre><p id="rfc.section.9.5.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 9.1</a>) whenever TE is present in an HTTP/1.1 message.2055 </pre><p id="rfc.section.9.5.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.5" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message. 1989 2056 </p> 1990 2057 <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> … … 2038 2105 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2039 2106 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body. 2040 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings2107 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 2041 2108 are not. 2042 2109 </p> … … 2073 2140 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2074 2141 </p> 2075 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection. 5" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2142 <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 9.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2076 2143 </p> 2077 2144 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it … … 2170 2237 <td class="left">http</td> 2171 2238 <td class="left">standard</td> 2172 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection. 6" title="Connection">Section 9.1</a>2239 <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 9.1</a> 2173 2240 </td> 2174 2241 </tr> … … 2735 2802 </p> 2736 2803 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2737 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2804 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2738 2805 </p> 2739 2806 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2815 2882 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 2816 2883 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 2817 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection. 7" title="Connection">Section 9.1</a>.2884 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 9.1</a>. 2818 2885 </p> 2819 2886 <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. … … 2825 2892 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2826 2893 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2827 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.1 0"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2894 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2828 2895 </p> 2829 2896 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 2836 2903 codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit, 2837 2904 so it was worth fixing <a href="#Nie1997" id="rfc.xref.Nie1997.2"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between 2838 authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#chunked.encoding" title="Chunked Transfer Coding">6.2.1</a>, and <a href="#header.te" id="rfc.xref.header.te.5" title="TE">9.5</a>) 2905 authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#chunked.encoding" title="Chunked Transfer Coding">6.2.1</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">7.1.3.2</a>, and <a href="#header.te" id="rfc.xref.header.te.5" title="TE">9.5</a>) 2906 </p> 2907 <p id="rfc.section.B.3.p.6">Proxies should be able to add Content-Length when appropriate. (<a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 7.1.3.2</a>) 2839 2908 </p> 2840 2909 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 2859 2928 <p id="rfc.section.B.4.p.8">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>) 2860 2929 </p> 2861 <p id="rfc.section.B.4.p.9">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection. 8" title="Connection">Section 9.1</a>)2930 <p id="rfc.section.B.4.p.9">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 9.1</a>) 2862 2931 </p> 2863 2932 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3292 3361 <p id="rfc.section.D.10.p.2">Partly resolved issues: </p> 3293 3362 <ul> 3363 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>>: "Placement of 13.5.1 and 13.5.2" 3364 </li> 3294 3365 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>>: "use of term "word" when talking about header structure" 3295 3366 </li> … … 3323 3394 <li class="indline1">compress (Coding Format) <a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li> 3324 3395 <li class="indline1">connection <a class="iref" href="#rfc.iref.c.2">2.1</a></li> 3325 <li class="indline1">Connection header <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc. iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>3396 <li class="indline1">Connection header <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li> 3326 3397 <li class="indline1">Content-Length header <a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 3327 3398 </ul> … … 3465 3536 <li class="indline1">Headers 3466 3537 <ul class="ind"> 3467 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc. iref.h.6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>3538 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1">3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.4</a></li> 3468 3539 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 3469 3540 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li> … … 3524 3595 </ul> 3525 3596 </li> 3526 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#rfc.xref.Part3.8"> 9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a>, <a class="iref" href="#rfc.xref.Part3.10">B.3</a><ul class="ind">3527 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3. 8">9.7</a></li>3597 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#rfc.xref.Part3.8">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.9">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.10">A</a>, <a class="iref" href="#rfc.xref.Part3.11">B.3</a><ul class="ind"> 3598 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.9">9.7</a></li> 3528 3599 <li class="indline1"><em>Section 2.3</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li> 3529 3600 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li> 3530 3601 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li> 3602 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.Part3.8">7.1.3.2</a></li> 3531 3603 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.7">6.4</a></li> 3532 3604 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> … … 3534 3606 </li> 3535 3607 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li> 3536 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="# Part6"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">B.3</a><ul class="ind">3608 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#rfc.xref.Part6.8">7.1.3.2</a>, <a class="iref" href="#Part6"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part6.9">B.3</a><ul class="ind"> 3537 3609 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.4">2.3</a></li> 3538 3610 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.5">3.5</a></li> 3539 3611 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a></li> 3540 <li class="indline1"><em>Section 3.6</em> <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a> </li>3612 <li class="indline1"><em>Section 3.6</em> <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#rfc.xref.Part6.8">7.1.3.2</a></li> 3541 3613 </ul> 3542 3614 </li>
Note: See TracChangeset
for help on using the changeset viewer.