Changeset 769 for draft-ietf-httpbis
- Timestamp:
- 04/03/10 14:34:38 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 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> -
draft-ietf-httpbis/latest/p1-messaging.xml
r767 r769 25 25 <!ENTITY entity-body "<xref target='Part3' x:rel='#entity.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 26 <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 <!ENTITY entity-length "<xref target='Part3' x:rel='#entity.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 28 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 29 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 2257 2258 implemented by many HTTP/1.0 clients). 2258 2259 </t> 2260 2261 <section title="End-to-end and Hop-by-hop Headers" anchor="end-to-end.and.hop-by-hop.headers"> 2262 <t> 2263 <cref anchor="TODO-end-to-end" source="jre"> 2264 Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>. 2265 See also <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60"/>. 2266 </cref> 2267 </t> 2268 <t> 2269 For the purpose of defining the behavior of caches and non-caching 2270 proxies, we divide HTTP headers into two categories: 2271 <list style="symbols"> 2272 <t>End-to-end headers, which are transmitted to the ultimate 2273 recipient of a request or response. End-to-end headers in 2274 responses MUST be stored as part of a cache entry and &MUST; be 2275 transmitted in any response formed from a cache entry.</t> 2276 2277 <t>Hop-by-hop headers, which are meaningful only for a single 2278 transport-level connection, and are not stored by caches or 2279 forwarded by proxies.</t> 2280 </list> 2281 </t> 2282 <t> 2283 The following HTTP/1.1 headers are hop-by-hop headers: 2284 <list style="symbols"> 2285 <t>Connection</t> 2286 <t>Keep-Alive</t> 2287 <t>Proxy-Authenticate</t> 2288 <t>Proxy-Authorization</t> 2289 <t>TE</t> 2290 <t>Trailer</t> 2291 <t>Transfer-Encoding</t> 2292 <t>Upgrade</t> 2293 </list> 2294 </t> 2295 <t> 2296 All other headers defined by HTTP/1.1 are end-to-end headers. 2297 </t> 2298 <t> 2299 Other hop-by-hop headers &MUST; be listed in a Connection header 2300 (<xref target="header.connection"/>). 2301 </t> 2302 </section> 2303 2304 <section title="Non-modifiable Headers" anchor="non-modifiable.headers"> 2305 <t> 2306 <cref anchor="TODO-non-mod-headers" source="jre"> 2307 Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>. 2308 See also <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60"/>. 2309 </cref> 2310 </t> 2311 <t> 2312 Some features of HTTP/1.1, such as Digest Authentication, depend on the 2313 value of certain end-to-end headers. A transparent proxy &SHOULD-NOT; 2314 modify an end-to-end header unless the definition of that header requires 2315 or specifically allows that. 2316 </t> 2317 <t> 2318 A transparent proxy &MUST-NOT; modify any of the following fields in a 2319 request or response, and it &MUST-NOT; add any of these fields if not 2320 already present: 2321 <list style="symbols"> 2322 <t>Content-Location</t> 2323 <t>Content-MD5</t> 2324 <t>ETag</t> 2325 <t>Last-Modified</t> 2326 </list> 2327 </t> 2328 <t> 2329 A transparent proxy &MUST-NOT; modify any of the following fields in a 2330 response: 2331 <list style="symbols"> 2332 <t>Expires</t> 2333 </list> 2334 </t> 2335 <t> 2336 but it &MAY; add any of these fields if not already present. If an 2337 Expires header is added, it &MUST; be given a field-value identical to 2338 that of the Date header in that response. 2339 </t> 2340 <t> 2341 A proxy &MUST-NOT; modify or add any of the following fields in a 2342 message that contains the no-transform cache-control directive, or in 2343 any request: 2344 <list style="symbols"> 2345 <t>Content-Encoding</t> 2346 <t>Content-Range</t> 2347 <t>Content-Type</t> 2348 </list> 2349 </t> 2350 <t> 2351 A non-transparent proxy &MAY; modify or add these fields to a message 2352 that does not include no-transform, but if it does so, it &MUST; add a 2353 Warning 214 (Transformation applied) if one does not already appear 2354 in the message (see &header-warning;). 2355 </t> 2356 <x:note> 2357 <t> 2358 <x:h>Warning:</x:h> Unnecessary modification of end-to-end headers might 2359 cause authentication failures if stronger authentication 2360 mechanisms are introduced in later versions of HTTP. Such 2361 authentication mechanisms &MAY; rely on the values of header fields 2362 not listed here. 2363 </t> 2364 </x:note> 2365 <t> 2366 The Content-Length field of a request or response is added or deleted 2367 according to the rules in <xref target="message.length"/>. A transparent proxy &MUST; 2368 preserve the entity-length (&entity-length;) of the entity-body, 2369 although it &MAY; change the transfer-length (<xref target="message.length"/>). 2370 </t> 2371 </section> 2372 2259 2373 </section> 2260 2374 … … 4638 4752 interoperability problem that could have occurred due to interactions 4639 4753 between authentication trailers, chunked encoding and HTTP/1.0 4640 clients.(Section <xref target="transfer.codings" format="counter"/>, <xref target="chunked.encoding" format="counter"/>, 4754 clients.(Section 4755 <xref target="transfer.codings" format="counter"/>, 4756 <xref target="chunked.encoding" format="counter"/>, 4757 <xref target="non-modifiable.headers" format="counter"/>, 4641 4758 and <xref target="header.te" format="counter"/>) 4759 </t> 4760 <t> 4761 Proxies should be able to add Content-Length when appropriate. 4762 (<xref target="non-modifiable.headers"/>) 4642 4763 </t> 4643 4764 </section> … … 5362 5483 <list style="symbols"> 5363 5484 <t> 5485 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>: 5486 "Placement of 13.5.1 and 13.5.2" 5487 </t> 5488 <t> 5364 5489 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: 5365 5490 "use of term "word" when talking about header structure" -
draft-ietf-httpbis/latest/p6-cache.html
r768 r769 1545 1545 <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">3.2</a>). 1546 1546 </p> 1547 <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1548 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1549 computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="TODO-nonmod">[<a href="#TODO-nonmod" class="smpl">TODO-nonmod</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1550 </p> 1551 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="TODO-nonmod2">[<a href="#TODO-nonmod2" class="smpl">TODO-nonmod2</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1552 </p> 1553 <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send 1547 <p id="rfc.section.A.1.p.2">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send 1554 1548 needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section 2.7</a>) 1555 1549 </p> 1556 <p id="rfc.section.A.1.p. 5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>)1557 </p> 1558 <p id="rfc.section.A.1.p. 6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.1550 <p id="rfc.section.A.1.p.3">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) 1551 </p> 1552 <p id="rfc.section.A.1.p.4">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1559 1553 </p> 1560 1554 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 1752 1746 <ul> 1753 1747 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/199">http://tools.ietf.org/wg/httpbis/trac/ticket/199</a>>: Status codes and caching 1748 </li> 1749 </ul> 1750 <p id="rfc.section.C.10.p.3">Partly resolved issues: </p> 1751 <ul> 1752 <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" 1754 1753 </li> 1755 1754 </ul> … … 1891 1890 </li> 1892 1891 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1893 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a> , <a class="iref" href="#rfc.xref.Part1.14">A.1</a><ul class="ind">1892 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 1894 1893 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a></li> 1895 1894 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li> … … 1905 1904 </ul> 1906 1905 </li> 1907 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>8.1</b></a> , <a class="iref" href="#rfc.xref.Part3.1">A.1</a></li>1906 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>8.1</b></a></li> 1908 1907 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#rfc.xref.Part4.3">2.7</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 1909 1908 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.3">2.7</a></li> … … 1911 1910 </ul> 1912 1911 </li> 1913 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#Part5"><b>8.1</b></a> , <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind">1912 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#Part5"><b>8.1</b></a><ul class="ind"> 1914 1913 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a></li> 1915 1914 </ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r768 r769 2028 2028 </t> 2029 2029 <t> 2030 Transfer-coding and message lengths all interact in ways that required fixing exactly2031 when chunked encoding is used (to allow for transfer encoding that may not be self2032 delimiting); it was important to straighten out exactly how message lengths are computed.2033 (see also <xref target="Part1" />, <xref target="Part3" /> and <xref target="Part5" />)2034 <cref anchor="TODO-nonmod" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>2035 </t>2036 <t>2037 Proxies should be able to add Content-Length when appropriate.2038 <cref anchor="TODO-nonmod2" source="jre">This used to refer to the text about non-modifiable headers, and will have to be updated later on.</cref>2039 </t>2040 <t>2041 2030 Range request responses would become very verbose if all meta-data were always returned; 2042 2031 by allowing the server to only send needed headers in a 206 response, this problem can be … … 2341 2330 </list> 2342 2331 </t> 2332 <t> 2333 Partly resolved issues: 2334 <list style="symbols"> 2335 <t> 2336 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>: 2337 "Placement of 13.5.1 and 13.5.2" 2338 </t> 2339 </list> 2340 </t> 2343 2341 </section> 2344 2342
Note: See TracChangeset
for help on using the changeset viewer.