Ignore:
Timestamp:
Jul 24, 2010, 2:24:23 AM (9 years ago)
Author:
julian.reschke@…
Message:

regen HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r900 r912  
    386386      <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7">
    387387      <link rel="Chapter" href="#rfc.section.8" title="8 References">
    388       <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A">
     388      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    389389      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    390390      <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
     
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-23">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 24, 2011</td>
     430               <td class="left">Expires: January 25, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 23, 2010</td>
     491               <td class="right">July 24, 2010</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire in January 24, 2011.</p>
     517      <p>This Internet-Draft will expire in January 25, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    594594         </li>
    595595         <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
    596          <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#compatibility">Compatibility with Previous Versions</a><ul class="toc">
    597                <li class="tocline1">A.1&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
    598                <li class="tocline1">A.2&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    599             </ul>
    600          </li>
     596         <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    601597         <li class="tocline0">B.&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
    602598         <li class="tocline0">C.&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul class="toc">
     
    625621      <p id="rfc.section.1.1.p.1">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache
    626622         stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.
    627          Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
     623         Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
    628624      </p>
    629625      <p id="rfc.section.1.1.p.2">Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior
     
    638634      <ul class="empty">
    639635         <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    640             Even when a response is cacheable, there may be additional constraints on whether a cache can use the cached copy to satisfy
     636            Even when a response is cacheable, there might be additional constraints on whether a cache can use the cached copy to satisfy
    641637            a particular request.
    642638         </li>
     
    803799      </p>
    804800      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    805          This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording may cause confusion, because the response may still be served stale.]</span>
    806       </p>
    807       <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
    808          when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate
    809          a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints
    810          on their results.
     801         This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording might cause confusion, because the response might still be served stale.]</span>
     802      </p>
     803      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other header values
     804         (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific
     805         algorithms, but does impose worst-case constraints on their results.
    811806      </p>
    812807      <div id="rfc.figure.u.3"></div>
     
    814809</pre> <p id="rfc.section.2.3.p.6">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    815810      </p>
    816       <p id="rfc.section.2.3.p.7">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
     811      <p id="rfc.section.2.3.p.7">Additionally, clients might need to influence freshness calculation. They can do this using several request cache directives,
    817812         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
    818813      </p>
     
    989984         </li>
    990985      </ul>
    991       <p id="rfc.section.2.7.p.3">If (after any normalisation that may take place) a header field is absent from a request, it can only match another request
     986      <p id="rfc.section.2.7.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request
    992987         if it is also absent there.
    993988      </p>
     
    1003998         be used to satisfy the request.
    1004999      </p>
    1005       <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: may need language about Content-Location here]</span><span class="comment" id="TODO-inm-mult-etags">[<a href="#TODO-inm-mult-etags" class="smpl">TODO-inm-mult-etags</a>: cover case where INM with multiple etags was sent]</span>
     1000      <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-inm-mult-etags">[<a href="#TODO-inm-mult-etags" class="smpl">TODO-inm-mult-etags</a>: cover case where INM with multiple etags was sent]</span>
    10061001      </p>
    10071002      <p id="rfc.section.2.8.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     
    10411036      </p>
    10421037      <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    1043          true, since HTTP/1.0 caches may not implement the Age header field.
     1038         true, since HTTP/1.0 caches might not implement the Age header field.
    10441039      </p>
    10451040      <div id="rfc.iref.c.3"></div>
     
    10901085         </li>
    10911086         <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    1092             might not recognize or obey this directive, and communications networks may be vulnerable to eavesdropping.
     1087            might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
    10931088         </li>
    10941089      </ul>
     
    11571152            with the listed response headers. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
    11581153         </li>
    1159          <li> <b>Note:</b> This usage of the word private only controls where the response may be stored, and cannot ensure the privacy of the message
     1154         <li> <b>Note:</b> This usage of the word private only controls where the response can be stored; it cannot ensure the privacy of the message
    11601155            content. Also, private response directives with field-names are often handled by implementations as if an unqualified private
    11611156            directive was received; i.e., the special handling for the qualified form is not widely implemented.
     
    11841179         </li>
    11851180         <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    1186             might not recognize or obey this directive, and communications networks may be vulnerable to eavesdropping.
     1181            might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
    11871182         </li>
    11881183      </ul>
     
    13251320      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    13261321         of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
    1327          response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server.
     1322         response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
    13281323      </p>
    13291324      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
     
    16811676               <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
    16821677      </div>
    1683       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    1684       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    1685       <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.4" title="Cache-Control">3.2</a>).
    1686       </p>
    1687       <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
    1688          needed headers in a 206 response, this problem can be avoided. (<a href="#combining.headers" title="Combining Responses">Section&nbsp;2.8</a>)
    1689       </p>
    1690       <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>)
    1691       </p>
    1692       <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.8</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" 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.
    1693       </p>
    1694       <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>
    1695       <p id="rfc.section.A.2.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>)
    1696       </p>
    1697       <p id="rfc.section.A.2.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
     1678      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
     1679      <p id="rfc.section.A.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>)
     1680      </p>
     1681      <p id="rfc.section.A.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
    16981682         use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
    16991683      </p>
    1700       <p id="rfc.section.A.2.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
    1701       </p>
    1702       <p id="rfc.section.A.2.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
    1703          (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;3.6</a>)
     1684      <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
     1685      </p>
     1686      <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
     1687         (<a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>)
    17041688      </p>
    17051689      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    19171901      </ul>
    19181902      <h2 id="rfc.section.C.12"><a href="#rfc.section.C.12">C.12</a>&nbsp;<a id="changes.since.10" href="#changes.since.10">Since draft-ietf-httpbis-p6-cache-10</a></h2>
    1919       <p id="rfc.section.C.12.p.1">None yet.</p>
     1903      <p id="rfc.section.C.12.p.1">Closed issues: </p>
     1904      <ul>
     1905         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
     1906         </li>
     1907      </ul>
    19201908      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    19211909      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a>
     
    19461934                     </ul>
    19471935                  </li>
    1948                   <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.3">5.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">A.1</a></li>
     1936                  <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.3">5.2</a></li>
    19491937                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">1.2</a></li>
    19501938               </ul>
     
    19951983                     <ul class="ind">
    19961984                        <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.xref.header.age.2">2.3.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.3">5.2</a></li>
    1997                         <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.3">5.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">A.1</a></li>
     1985                        <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.3">5.2</a></li>
    19981986                        <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.1</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.3">2.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.4">5.2</a></li>
    19991987                        <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.2</a></li>
    20001988                        <li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">2.7</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.2</a></li>
    2001                         <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.8</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.2</a></li>
     1989                        <li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.8</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">A</a></li>
    20021990                     </ul>
    20031991                  </li>
     
    21392127            </li>
    21402128            <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind">
    2141                   <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.8</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.2</a></li>
     2129                  <li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.8</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">A</a></li>
    21422130               </ul>
    21432131            </li>
Note: See TracChangeset for help on using the changeset viewer.