Changeset 769 for draft-ietf-httpbis


Ignore:
Timestamp:
Mar 4, 2010, 6:34:38 AM (10 years ago)
Author:
julian.reschke@…
Message:

Restore sections "End-to-end and Hop-by-hop Headers" and ""Non-modifiable Headers" in Part 1 for now (relates to #60)

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

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

    r767 r769  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-03-03">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-03-04">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: September 4, 2010</td>
     437               <td class="left">Expires: September 5, 2010</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">March 3, 2010</td>
     490               <td class="right">March 4, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    520520      <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>.
    521521      </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>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    610610                        </ul>
    611611                     </li>
    612                      <li class="tocline1">7.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a></li>
     612                     <li class="tocline1">7.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul class="toc">
     613                           <li class="tocline1">7.1.3.1&nbsp;&nbsp;&nbsp;<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&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.headers">Non-modifiable Headers</a></li>
     615                        </ul>
     616                     </li>
    613617                     <li class="tocline1">7.1.4&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    614618                  </ul>
    … …  
    17141718      <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).
    17151719      </p>
     1720      <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<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 &lt;<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>&gt;. See also &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60</a>&gt;. --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&nbsp;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>&nbsp;<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 &lt;<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>&gt;. See also &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60</a>&gt;. --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&nbsp;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&nbsp;3.4</a>).
     1782      </p>
    17161783      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    17171784      <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
    … …  
    19862053  TE:
    19872054  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&nbsp;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&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
    19892056      </p>
    19902057      <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>
    … …  
    20382105      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    20392106      <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-codings
     2107         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
    20412108         are not.
    20422109      </p>
    … …  
    20732140         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.
    20742141      </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&nbsp;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&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    20762143      </p>
    20772144      <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
    … …  
    21702237                  <td class="left">http</td>
    21712238                  <td class="left">standard</td>
    2172                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>
     2239                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a>
    21732240                  </td>
    21742241               </tr>
    … …  
    27352802      </p>
    27362803      <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>.
    27382805      </p>
    27392806      <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>
    … …  
    28152882         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    28162883         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&nbsp;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&nbsp;9.1</a>.
    28182885      </p>
    28192886      <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>.
    … …  
    28252892      <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
    28262893         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.10"><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>)
    28282895      </p>
    28292896      <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
    … …  
    28362903         codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit,
    28372904         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&nbsp;7.1.3.2</a>)
    28392908      </p>
    28402909      <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    28592928      <p id="rfc.section.B.4.p.8">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
    28602929      </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&nbsp;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&nbsp;9.1</a>)
    28622931      </p>
    28632932      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    32923361      <p id="rfc.section.D.10.p.2">Partly resolved issues: </p>
    32933362      <ul>
     3363         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>&gt;: "Placement of 13.5.1 and 13.5.2"
     3364         </li>
    32943365         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
    32953366         </li>
    … …  
    33233394                  <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li>
    33243395                  <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.1</a></li>
    3325                   <li class="indline1">Connection header&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    33263397                  <li class="indline1">Content-Length header&nbsp;&nbsp;<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>
    33273398               </ul>
    … …  
    34653536                  <li class="indline1">Headers&nbsp;&nbsp;
    34663537                     <ul class="ind">
    3467                         <li class="indline1">Connection&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    34683539                        <li class="indline1">Content-Length&nbsp;&nbsp;<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>
    34693540                        <li class="indline1">Date&nbsp;&nbsp;<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>
    … …  
    35243595                     </ul>
    35253596                  </li>
    3526                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">9.7</a></li>
     3597                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.9">9.7</a></li>
    35283599                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    35293600                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<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>
    35303601                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
     3602                        <li class="indline1"><em>Section 3.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">7.1.3.2</a></li>
    35313603                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">6.4</a></li>
    35323604                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    … …  
    35343606                  </li>
    35353607                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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">
    35373609                        <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">2.3</a></li>
    35383610                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">3.5</a></li>
    35393611                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    35413613                     </ul>
    35423614                  </li>

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

    r767 r769  
    2525  <!ENTITY entity-body            "<xref target='Part3' x:rel='#entity.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!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'/>">
    2728  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    22572258   implemented by many HTTP/1.0 clients).
    22582259</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
    22592373</section>
    22602374
    … …  
    46384752   interoperability problem that could have occurred due to interactions
    46394753   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"/>,
    46414758   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"/>)
    46424763</t>
    46434764</section>
    … …  
    53625483  <list style="symbols">
    53635484    <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>
    53645489      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
    53655490      "use of term "word" when talking about header structure"

  • draft-ietf-httpbis/latest/p6-cache.html

    r768 r769  
    15451545      <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>).
    15461546      </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
    15541548         needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>)
    15551549      </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&nbsp;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&nbsp;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.
    15591553      </p>
    15601554      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    17521746      <ul>
    17531747         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/199">http://tools.ietf.org/wg/httpbis/trac/ticket/199</a>&gt;: 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> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>&gt;: "Placement of 13.5.1 and 13.5.2"
    17541753         </li>
    17551754      </ul>
    … …  
    18911890            </li>
    18921891            <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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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">
    18941893                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a></li>
    18951894                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<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>
    … …  
    19051904                     </ul>
    19061905                  </li>
    1907                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#Part3"><b>8.1</b></a></li>
    19081907                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<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">
    19091908                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.3">2.7</a></li>
    … …  
    19111910                     </ul>
    19121911                  </li>
    1913                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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">
    19141913                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">2.1.1</a></li>
    19151914                     </ul>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r768 r769  
    20282028</t>
    20292029<t>
    2030   Transfer-coding and message lengths all interact in ways that required fixing exactly
    2031   when chunked encoding is used (to allow for transfer encoding that may not be self
    2032   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>
    20412030  Range request responses would become very verbose if all meta-data were always returned;
    20422031  by allowing the server to only send needed headers in a 206 response, this problem can be
    … …  
    23412330  </list>
    23422331</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>
    23432341</section>
    23442342
Note: See TracChangeset for help on using the changeset viewer.