Changeset 529


Ignore:
Timestamp:
Mar 5, 2009, 12:30:54 AM (11 years ago)
Author:
julian.reschke@…
Message:

regenerate HTML

File:
1 edited

Legend:

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

    r501 r529  
    369369      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    370370      <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
    371       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.424, 2009-02-24 16:15:29, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     371      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.425, 2009-03-02 15:29:33, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    372372      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    373373      <meta name="DC.Creator" content="Fielding, R.">
     
    465465         <tr>
    466466            <td class="header left"></td>
    467             <td class="header right">March 4, 2009</td>
     467            <td class="header right">March 5, 2009</td>
    468468         </tr>
    469469      </table>
     
    693693         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers, and
    694694         </li>
    695          <li>the "private" cache response directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> does not appear in the response, if the cache is a shared cache, and
     695         <li>the "private" cache response directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> does not appear in the response, if the cache is shared, and
     696         </li>
     697         <li>the "Authorization" header (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared (unless the "public" directive is present; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a>), and
    696698         </li>
    697699         <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section&nbsp;2.1.1</a>).
     
    707709      </p>
    708710      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
    709       <p id="rfc.section.2.2.p.1">For a presented request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     711      <p id="rfc.section.2.2.p.1">For a presented request, a cache <em class="bcp14">MAY</em> return a stored response, provided that:
    710712      </p>
    711713      <ul>
     
    714716         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    715717         <li>selecting request-headers nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
     718         </li>
     719         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), and
    716720         </li>
    717721         <li>the stored response is either:
     
    723727               <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
    724728               </li>
    725             </ul>and
    726          </li>
    727          <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
     729            </ul>
    728730         </li>
    729731      </ul>
    730       <p id="rfc.section.2.2.p.2">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
    731       </p>
    732       <ul>
    733          <li>The criteria for non-shared caches above are met (taking into account directives specific to shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>), and
    734          </li>
    735          <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>).
    736          </li>
    737       </ul>
    738       <p id="rfc.section.2.2.p.3"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p>
    739       <p id="rfc.section.2.2.p.4">All responses satisfied from cache include an appropriate Age header field; see <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p>
    740       <p id="rfc.section.2.2.p.5">Request methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
     732      <p id="rfc.section.2.2.p.2"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p>
     733      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p>
     734      <p id="rfc.section.2.2.p.4">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
    741735         the request and having received a corresponding response.
    742736      </p>
    743       <p id="rfc.section.2.2.p.6">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
    744       </p>
    745       <p id="rfc.section.2.2.p.7">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They <em class="bcp14">MAY</em> also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
    746       </p>
    747       <p id="rfc.section.2.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
     737      <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
     738      </p>
     739      <p id="rfc.section.2.2.p.6">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They <em class="bcp14">MAY</em> also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     740      </p>
     741      <p id="rfc.section.2.2.p.7"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
    748742      </p>
    749743      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     
    769763         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>.
    770764      </p>
    771       <p id="rfc.section.2.3.p.9">Note that reshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     765      <p id="rfc.section.2.3.p.9"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     766      </p>
     767      <p id="rfc.section.2.3.p.10">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
    772768         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
    773       </p>
    774       <p id="rfc.section.2.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    775769      </p>
    776770      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
     
    804798         path from the origin server, plus the amount of time it has been in transit along network paths.
    805799      </p>
    806       <p id="rfc.section.2.3.2.p.2">When a stored response is used to satisfy a request, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
    807          the algorithm described in this section.
    808       </p>
    809       <p id="rfc.section.2.3.2.p.3">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p>
    810       <p id="rfc.section.2.3.2.p.4">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
     800      <p id="rfc.section.2.3.2.p.2">The term "age_value" denotes the value of the Age header, in a form appropriate for arithmetic operations.</p>
     801      <p id="rfc.section.2.3.2.p.3">HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
    811802         was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
    812803      </p>
    813       <p id="rfc.section.2.3.2.p.5">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially
     804      <p id="rfc.section.2.3.2.p.4">The term "now" means "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially
    814805         hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a> or some similar protocol to synchronize their clocks to a globally accurate time standard.
    815806      </p>
    816       <p id="rfc.section.2.3.2.p.6">A response's age can be calculated in two entirely independent ways: </p>
     807      <p id="rfc.section.2.3.2.p.5">A response's age can be calculated in two entirely independent ways: </p>
    817808      <ol>
    818809         <li>now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative,
     
    821812         <li>age_value, if all of the caches along the response path implement HTTP/1.1.</li>
    822813      </ol>
    823       <p id="rfc.section.2.3.2.p.7">These are combined as</p>
     814      <p id="rfc.section.2.3.2.p.6">These are combined as</p>
    824815      <div id="rfc.figure.u.4"></div> <pre class="text">    corrected_received_age = max(now - date_value, age_value)
    825 </pre> <p id="rfc.section.2.3.2.p.9">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
     816</pre> <p id="rfc.section.2.3.2.p.8">When an Age value is received, it <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
    826817      </p>
    827818      <div id="rfc.figure.u.5"></div> <pre class="text">   corrected_initial_age = corrected_received_age
    828819                         + (now - request_time)
    829 </pre> <p id="rfc.section.2.3.2.p.11">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
    830       <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
     820</pre> <p id="rfc.section.2.3.2.p.10">where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.</p>
     821      <p id="rfc.section.2.3.2.p.11">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
    831822         was last validated by the origin server to the corrected_initial_age.
    832823      </p>
    833       <p id="rfc.section.2.3.2.p.13">In summary:</p>
    834       <div id="rfc.figure.u.6"></div> <pre class="text">   /*
    835     * age_value
    836     *      is the value of Age: header received by the cache with
    837     *              this response.
    838     * date_value
    839     *      is the value of the origin server's Date: header
    840     * request_time
    841     *      is the (local) time when the cache made the request
    842     *              that resulted in this stored response
    843     * response_time
    844     *      is the (local) time when the cache received the
    845     *              response
    846     * now
    847     *      is the current (local) time
    848     */
     824      <p id="rfc.section.2.3.2.p.12">In summary:</p>
     825      <div id="rfc.figure.u.6"></div> <pre class="text">   age_value     - Age header field-value received with the response
     826   date_value    - Date header field-value received with the response
     827   request_time  - local time when the cache made the request
     828                   resulting in the stored response
     829   response_time - local time when the cache received the response
     830   now           - current local time
    849831
    850832   apparent_age = max(0, response_time - date_value);
     
    858840         but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
    859841      </p>
    860       <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    861       </p>
    862       <p id="rfc.section.2.3.3.p.3">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
    863       </p>
    864       <p id="rfc.section.2.3.3.p.4">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     842      <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MAY</em> return a stale response if disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or explicitly
     843         allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
     844      </p>
     845      <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    865846         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    866847         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
    867848      </p>
    868       <p id="rfc.section.2.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>).
     849      <p id="rfc.section.2.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
     850      </p>
     851      <p id="rfc.section.2.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
    869852      </p>
    870853      <p id="rfc.section.2.3.3.p.6">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
     
    883866      <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace
    884867         the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p>
    885       <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     868      <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    886869      </p>
    887870      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
     
    911894      </p>
    912895      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    913       <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions and procedure by which a cache can use the response for subsequent requests.
    914       </p>
    915       <p id="rfc.section.2.6.p.2">When the cache receives a request which may be satisfied by a stored response that includes a Vary header field <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>, it <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless all of the selecting request-headers present in the new request match
    916          the corresponding stored request-headers from the original request.
     896      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions under which a cache can use the response for subsequent requests.
     897      </p>
     898      <p id="rfc.section.2.6.p.2">When a cache receives a request that can be satisfied by a stored response that includes a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers in the presented request match the corresponding stored request-headers
     899         from the original request.
    917900      </p>
    918901      <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
     
    922905         by the origin server.
    923906      </p>
    924       <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, which <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with
     907      <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, and <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with
    925908         304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>.
    926909      </p>
     
    941924      <p id="rfc.section.2.7.p.3">The stored response headers are used for the updated response, except that </p>
    942925      <ul>
    943          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.
     926         <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.
    944927         </li>
    945928         <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the forwarded response.
     
    948931         </li>
    949932      </ul>
    950       <p id="rfc.section.2.7.p.4">A cache <em class="bcp14">MUST</em> also replace stored headers with corresponding headers received in the incoming response, except for Warning headers as described
    951          immediately above. If a header field-name in the incoming response matches more than one header in the stored response, all
    952          such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body.
     933      <p id="rfc.section.2.7.p.4">A cache <em class="bcp14">MUST</em> also replace any stored headers with corresponding headers received in the incoming response, except for Warning headers as
     934         described immediately above. If a header field-name in the incoming response matches more than one header in the stored response,
     935         all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.
    953936      </p>
    954937      <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p>
     
    10371020            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    10381021            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1039             a stale response of any age.
    1040          </dd>
     1022            a stale response of any age. <span class="comment">[rfc.comment.15: of any staleness? -- mnot]</span></dd>
    10411023      </dl>
    10421024      <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> min-fresh
     
    10961078      </p>
    10971079      <dl class="empty">
    1098          <dd>The no-cache response directive indicates that a response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to
     1080         <dd>The no-cache response directive indicates that the response <em class="bcp14">MUST NOT</em> be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to
    10991081            prevent caching even by caches that have been configured to return stale responses.
    11001082         </dd>
     
    11181100      </p>
    11191101      <dl class="empty">
    1120          <dd>The must-revalidate response directive indicates that validation is required before the response is used by a cache to satisfy
    1121             any request.
    1122          </dd>
    1123          <dd>When the present, caches <em class="bcp14">MUST NOT</em> use a stored after it becomes stale to respond to a subsequent request without first validating it with the origin server.
     1102         <dd>The must-revalidate response directive indicates that once it has become stale, the response <em class="bcp14">MUST NOT</em> be used to satisfy subsequent requests without successful validation on the origin server.
    11241103         </dd>
    11251104         <dd>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
     
    11601139      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    11611140      <p id="rfc.section.3.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
    1162          value. Informational extensions (those which do not require a change in cache behavior) <em class="bcp14">MAY</em> be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers
     1141         value. Informational extensions (those that do not require a change in cache behavior) <em class="bcp14">MAY</em> be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers
    11631142         to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications
    1164          which do not understand the new directive will default to the behavior specified by the standard directive, and those that
     1143         that do not understand the new directive will default to the behavior specified by the standard directive, and those that
    11651144         understand the new directive will recognize it as modifying the requirements associated with the standard directive. In this
    11661145         way, extensions to the cache-control directives can be made without requiring changes to the base protocol.
     
    11691148         obeying certain extensions, and ignoring all directives that it does not understand.
    11701149      </p>
    1171       <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" which acts as a modifier to the private directive.
    1172          We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members
    1173          of the community named within its value may cache the response. An origin server wishing to allow the UCI community to use
    1174          an otherwise private response in their shared cache(s) could do so by including
     1150      <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
     1151         We define this new directive to mean that, in addition to any non-shared cache, any cache that is shared only by members of
     1152         the community named within its value may cache the response. An origin server wishing to allow the UCI community to use an
     1153         otherwise private response in their shared cache(s) could do so by including
    11751154      </p>
    11761155      <div id="rfc.figure.u.12"></div> <pre class="text">  Cache-Control: private, community="UCI"
     
    11851164      <div id="rfc.iref.h.4"></div>
    11861165      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1187       <p id="rfc.section.3.3.p.1">The entity-header field "Expires" gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the expiration model.
     1166      <p id="rfc.section.3.3.p.1">The entity-header field "Expires" gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
    11881167      </p>
    11891168      <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
     
    11981177</pre> <p id="rfc.section.3.3.p.7"> </p>
    11991178      <dl class="empty">
    1200          <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field.
     1179         <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
    12011180         </dd>
    12021181      </dl>
     
    12291208      <div id="rfc.iref.h.6"></div>
    12301209      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    1231       <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that fully determines, while the response
    1232          is fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation. For uncacheable
    1233          or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation.
    1234          A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this
    1235          response is the appropriate representation. See <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a> for use of the Vary header field by caches.
     1210      <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that determines, while the response is
     1211         fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
     1212      </p>
     1213      <p id="rfc.section.3.5.p.2">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
     1214         the representation.
    12361215      </p>
    12371216      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#header.vary" class="smpl">Vary</a>   = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a>
    12381217  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    1239 </pre><p id="rfc.section.3.5.p.3">The set of header fields named by the Vary field value is known as the "selecting" request-headers.</p>
    1240       <p id="rfc.section.3.5.p.4">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
     1218</pre><p id="rfc.section.3.5.p.4">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
     1219      <p id="rfc.section.3.5.p.5">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
    12411220         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    12421221         resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
    12431222         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    12441223      </p>
    1245       <p id="rfc.section.3.5.p.5">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    1246          of the client), play a role in the selection of the response representation. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server.
    1247       </p>
    1248       <p id="rfc.section.3.5.p.6">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
     1224      <p id="rfc.section.3.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
     1225         of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
     1226         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.
     1227      </p>
     1228      <p id="rfc.section.3.5.p.7">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
    12491229         are case-insensitive.
    12501230      </p>
     
    12531233      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
    12541234      <p id="rfc.section.3.6.p.1">The general-header field "Warning" is used to carry additional information about the status or transformation of a message
    1255          which might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
     1235         that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    12561236         by caching operations or transformations applied to the entity body of the message.
    12571237      </p>
     
    12951275         </li>
    12961276         <li>2xx Warnings that describe some aspect of the entity body or entity headers that is not rectified by a validation (for example,
    1297             a lossy compression of the entity bodies) and which <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
     1277            a lossy compression of the entity bodies) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
    12981278         </li>
    12991279      </ul>
     
    13551335      </dl>
    13561336      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
    1357       <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity
     1337      <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay an entity
    13581338         retrieved earlier in a session.
    13591339      </p>
     
    14011381                  <td>http</td>
    14021382                  <td>standard</td>
    1403                   <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section&nbsp;3.2</a>
     1383                  <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>
    14041384                  </td>
    14051385               </tr>
     
    14291409                  <td>http</td>
    14301410                  <td>standard</td>
    1431                   <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>
     1411                  <td> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>
    14321412                  </td>
    14331413               </tr>
     
    15381518      <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    15391519      <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>
    1540       <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.7" title="Cache-Control">3.2</a>).
     1520      <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.6" title="Cache-Control">3.2</a>).
    15411521      </p>
    15421522      <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
     
    15491529      </p>
    15501530      <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p>
    1551       <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <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.8" 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.
     1531      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <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.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.5" 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.
    15521532      </p>
    15531533      <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>
     
    17141694                     </ul>
    17151695                  </li>
    1716                   <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.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">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.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
     1696                  <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.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">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.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
    17171697                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">1.2</a></li>
    17181698               </ul>
     
    17631743                     <ul class="ind">
    17641744                        <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li>
    1765                         <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.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">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.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
     1745                        <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.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">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.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
    17661746                        <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">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.3">5.1</a></li>
    17671747                        <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.1</a></li>
    17681748                        <li class="indline1">Vary&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li>
    1769                         <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.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
     1749                        <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.4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>
    17701750                     </ul>
    17711751                  </li>
     
    18531833                     </ul>
    18541834                  </li>
    1855                   <li class="indline1"><em>Part7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.2</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a>, <a class="iref" href="#Part7"><b>8.1</b></a><ul class="ind">
    1856                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.2</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a></li>
     1835                  <li class="indline1"><em>Part7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.1</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a>, <a class="iref" href="#Part7"><b>8.1</b></a><ul class="ind">
     1836                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part7.1">2.1</a>, <a class="iref" href="#rfc.xref.Part7.2">3.2.2</a></li>
    18571837                     </ul>
    18581838                  </li>
     
    19021882            </li>
    19031883            <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind">
    1904                   <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.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li>
     1884                  <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.4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>
    19051885               </ul>
    19061886            </li>
Note: See TracChangeset for help on using the changeset viewer.