Changeset 2247


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

Address editorial feedback from Alex; see #480

Location:
draft-ietf-httpbis/latest
Files:
2 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:
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2246 r2247  
    204204</artwork></figure>
    205205<t>
    206    If an implementation receives a delta-seconds value larger than the largest
     206   If a cache receives a delta-seconds value larger than the largest
    207207   positive integer it can represent, or if any of its subsequent calculations
    208208   overflows, it &MUST; consider the value to be 2147483648
    209209   (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use
    210210   an arithmetic type of at least 31 bits of range, and senders &MUST-NOT;
    211    send delta-seconds with a value greater than 2147483648.
     211   generate delta-seconds with a value greater than 2147483648.
    212212</t>
    213213</section>
     
    246246   The primary <x:dfn>cache key</x:dfn> consists of the request method and
    247247   target URI.  However, since HTTP caches in common use today are typically
    248    limited to caching responses to GET, many implementations simply decline
     248   limited to caching responses to GET, many caches simply decline
    249249   other methods and use only the URI as the primary cache key.
    250250</t>
     
    736736</t>
    737737<t>
    738    A cache &MUST-NOT; send a stale response if it is prohibited by an
     738   A cache &MUST-NOT; generate a stale response if it is prohibited by an
    739739   explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    740740   directive, a "must-revalidate" cache-response-directive, or an applicable
     
    760760   an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that
    761761   it would normally forward to the requesting client, and the received
    762    response is no longer fresh, the cache can forward it to the requesting
     762   response is no longer fresh, the cache &MAY; forward it to the requesting
    763763   client without adding a new <x:ref>Warning</x:ref> (but without removing
    764764   any existing Warning header fields). A cache shouldn't attempt to validate
     
    845845     &weak-and-strong;), then that strong validator identifies the selected
    846846     representation for update. All of the stored responses with the same
    847      strong validator are selected. If none of the stored responses contain
    848      the same strong validator, then the new response &MUST-NOT; be used to
     847     strong validator are selected. If none of the stored responses contain the
     848     same strong validator, then the cache &MUST-NOT; use the new response to
    849849     update any stored responses.
    850850    </t>
     
    12831283   &Note; Although it has been back-ported to many implementations, some
    12841284   HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
    1285    response directives with field-names are often handled by implementations
     1285   response directives with field-names are often handled by caches
    12861286   as if an unqualified no-cache directive was received; i.e., the special
    12871287   handling for the qualified form is not widely implemented.
     
    13671367   where the response can be stored; it cannot ensure the privacy of the
    13681368   message content. Also, private response directives with field-names are
    1369    often handled by implementations as if an unqualified private directive
     1369   often handled by caches as if an unqualified private directive
    13701370   was received; i.e., the special handling for the qualified form is not
    13711371   widely implemented.
     
    15791579<t>
    15801580   When the <x:ref>Cache-Control</x:ref> header field is not present in a
    1581    request, the no-cache request pragma-directive &MUST; have the same effect
    1582    on caches as if "Cache-Control: no-cache" were present (see <xref
    1583    target="cache-request-directive" />).
     1581   request, caches &MUST; consider the no-cache request pragma-directive as
     1582   having the same effect as if "Cache-Control: no-cache" were present (see
     1583   <xref target="cache-request-directive" />).
    15841584</t>
    15851585<t>
Note: See TracChangeset for help on using the changeset viewer.