Ignore:
Timestamp:
May 8, 2013, 6:06:21 AM (6 years ago)
Author:
mnot@…
Message:

Address editorial feedback from Alex; see #480

File:
1 edited

Legend:

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

    r2246 r2247  
    452452  }
    453453  @bottom-center {
    454        content: "Expires November 8, 2013";
     454       content: "Expires November 9, 2013";
    455455  }
    456456  @bottom-right {
     
    492492      <link href="p5-range.html" rel="prev">
    493493      <link href="p7-auth.html" rel="next">
    494       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     494      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/">
    495495      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    496496      <meta name="dct.creator" content="Fielding, R.">
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-05-07">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-05-08">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: November 8, 2013</td>
     526               <td class="left">Expires: November 9, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">May 7, 2013</td>
     535               <td class="right">May 8, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on November 8, 2013.</p>
     561      <p>This Internet-Draft will expire on November 9, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    720720      <p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
    721721      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    722 </pre><p id="rfc.section.1.2.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
    723          its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
     722</pre><p id="rfc.section.1.2.1.p.3">If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent
     723         calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> generate delta-seconds with a value greater than 2147483648.
    724724      </p>
    725725      <div id="rfc.iref.c.2"></div>
     
    737737      <div id="rfc.iref.c.4"></div>
    738738      <p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching
    739          responses to GET, many implementations simply decline other methods and use only the URI as the primary cache key.
     739         responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.
    740740      </p>
    741741      <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated
     
    998998         is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>.
    999999      </p>
    1000       <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> send a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     1000      <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    10011001         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    10021002         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>).
     
    10081008      </p>
    10091009      <div id="rfc.iref.f.3"></div>
    1010       <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache
    1011          can forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because
     1010      <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">MAY</em> forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because
    10121011         that response became stale in transit.
    10131012      </p>
     
    10471046      <ul>
    10481047         <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
    1049             strong validator are selected. If none of the stored responses contain the same strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses.
     1048            strong validator are selected. If none of the stored responses contain the same strong validator, then the cache <em class="bcp14">MUST NOT</em> use the new response to update any stored responses.
    10501049         </li>
    10511050         <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
     
    12591258      <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
    12601259      <p id="rfc.section.7.2.2.2.p.5"> <b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.
    1261          Also, no-cache response directives with field-names are often handled by implementations as if an unqualified no-cache directive
    1262          was received; i.e., the special handling for the qualified form is not widely implemented.
     1260         Also, no-cache response directives with field-names are often handled by caches as if an unqualified no-cache directive was
     1261         received; i.e., the special handling for the qualified form is not widely implemented.
    12631262      </p>
    12641263      <p id="rfc.section.7.2.2.2.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     
    12941293      <p id="rfc.section.7.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
    12951294      <p id="rfc.section.7.2.2.6.p.5"> <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
    1296          content. Also, private response directives with field-names are often handled by implementations as if an unqualified private
    1297          directive was received; i.e., the special handling for the qualified form is not widely implemented.
     1295         content. Also, private response directives with field-names are often handled by caches as if an unqualified private directive
     1296         was received; i.e., the special handling for the qualified form is not widely implemented.
    12981297      </p>
    12991298      <p id="rfc.section.7.2.2.6.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     
    14001399  <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
    14011400  <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ]
    1402 </pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
     1401</pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    14031402      </p>
    14041403      <p id="rfc.section.7.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
Note: See TracChangeset for help on using the changeset viewer.