Changeset 2371
- Timestamp:
- 07/09/13 19:26:15 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r2369 r2371 449 449 } 450 450 @bottom-center { 451 content: "Expires March 8, 2014";451 content: "Expires March 11, 2014"; 452 452 } 453 453 @bottom-right { … … 495 495 <meta name="dct.creator" content="Reschke, J. F."> 496 496 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 497 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 4">497 <meta name="dct.issued" scheme="ISO8601" content="2013-09-07"> 498 498 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 499 499 <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."> … … 521 521 </tr> 522 522 <tr> 523 <td class="left">Expires: March 8, 2014</td>523 <td class="left">Expires: March 11, 2014</td> 524 524 <td class="right">J. Reschke, Editor</td> 525 525 </tr> … … 530 530 <tr> 531 531 <td class="left"></td> 532 <td class="right">September 4, 2013</td>532 <td class="right">September 7, 2013</td> 533 533 </tr> 534 534 </tbody> … … 556 556 in progress”. 557 557 </p> 558 <p>This Internet-Draft will expire on March 8, 2014.</p>558 <p>This Internet-Draft will expire on March 11, 2014.</p> 559 559 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 560 560 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 590 590 </li> 591 591 <li><a href="#rfc.section.4">4.</a> <a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul> 592 <li><a href="#rfc.section.4.1">4.1</a> <a href="#expiration.model">Freshness</a><ul> 593 <li><a href="#rfc.section.4.1.1">4.1.1</a> <a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li> 594 <li><a href="#rfc.section.4.1.2">4.1.2</a> <a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li> 595 <li><a href="#rfc.section.4.1.3">4.1.3</a> <a href="#age.calculations">Calculating Age</a></li> 596 <li><a href="#rfc.section.4.1.4">4.1.4</a> <a href="#serving.stale.responses">Serving Stale Responses</a></li> 592 <li><a href="#rfc.section.4.1">4.1</a> <a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li> 593 <li><a href="#rfc.section.4.2">4.2</a> <a href="#expiration.model">Freshness</a><ul> 594 <li><a href="#rfc.section.4.2.1">4.2.1</a> <a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li> 595 <li><a href="#rfc.section.4.2.2">4.2.2</a> <a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li> 596 <li><a href="#rfc.section.4.2.3">4.2.3</a> <a href="#age.calculations">Calculating Age</a></li> 597 <li><a href="#rfc.section.4.2.4">4.2.4</a> <a href="#serving.stale.responses">Serving Stale Responses</a></li> 597 598 </ul> 598 599 </li> 599 <li><a href="#rfc.section.4. 2">4.2</a> <a href="#validation.model">Validation</a><ul>600 <li><a href="#rfc.section.4. 2.1">4.2.1</a> <a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li>600 <li><a href="#rfc.section.4.3">4.3</a> <a href="#validation.model">Validation</a><ul> 601 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li> 601 602 </ul> 602 603 </li> 603 <li><a href="#rfc.section.4.3">4.3</a> <a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li>604 604 </ul> 605 605 </li> … … 703 703 </div> 704 704 <p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current 705 request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section 4. 1</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains705 request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section 4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains 706 706 valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When 707 a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section 4. 2</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.1.4</a>).707 a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section 4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>). 708 708 </p> 709 709 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> … … 739 739 </p> 740 740 <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 741 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>).741 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>). 742 742 </p> 743 743 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="response.cacheability" href="#response.cacheability">Storing Responses in Caches</a></h1> … … 763 763 <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>) that allows it to be cached, or 764 764 </li> 765 <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a>), or765 <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>), or 766 766 </li> 767 767 <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section 7.2.2.5</a>). … … 792 792 </p> 793 793 <p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be 794 served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section 4. 1.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy794 served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy 795 795 a subsequent request without revalidating it on the origin server. 796 796 </p> … … 817 817 </li> 818 818 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 819 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>), and820 </li> 821 <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 7.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section 4. 2</a>), and822 </li> 823 <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section 4. 2</a>), and819 <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), and 820 </li> 821 <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 7.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and 822 </li> 823 <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section 4.3</a>), and 824 824 </li> 825 825 <li>the stored response is either: 826 826 <ul> 827 <li>fresh (see <a href="#expiration.model" title="Freshness">Section 4. 1</a>), or827 <li>fresh (see <a href="#expiration.model" title="Freshness">Section 4.2</a>), or 828 828 </li> 829 <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4. 1.4</a>), or829 <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>), or 830 830 </li> 831 <li>successfully validated (see <a href="#validation.model" title="Validation">Section 4. 2</a>).831 <li>successfully validated (see <a href="#validation.model" title="Validation">Section 4.3</a>). 832 832 </li> 833 833 </ul> … … 836 836 <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a>. 837 837 </p> 838 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4. 1.3</a>.838 <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>. 839 839 </p> 840 840 <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request … … 848 848 <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them upon every use. 849 849 </p> 850 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2> 851 <p id="rfc.section.4.1.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original 852 request (i.e., that associated with the stored response), and the presented request. 853 </p> 854 <p id="rfc.section.4.1.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed 855 to those in the second request by applying any of the following: 856 </p> 857 <ul> 858 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 859 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) 860 </li> 861 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification 862 (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive) 863 </li> 864 </ul> 865 <p id="rfc.section.4.1.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request 866 if it is also absent there. 867 </p> 868 <p id="rfc.section.4.1.p.4">A <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match. 869 </p> 870 <p id="rfc.section.4.1.p.5">The stored response with matching selecting header fields is known as the selected response.</p> 871 <p id="rfc.section.4.1.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will 872 need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a>. 873 </p> 874 <p id="rfc.section.4.1.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin 875 server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section 4.3</a>) request. 876 </p> 850 877 <div id="rfc.iref.f.1"></div> 851 878 <div id="rfc.iref.s.2"></div> 852 <h2 id="rfc.section.4. 1"><a href="#rfc.section.4.1">4.1</a> <a id="expiration.model" href="#expiration.model">Freshness</a></h2>853 <p id="rfc.section.4. 1.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.879 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="expiration.model" href="#expiration.model">Freshness</a></h2> 880 <p id="rfc.section.4.2.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has. 854 881 </p> 855 882 <div id="rfc.iref.f.2"></div> 856 883 <div id="rfc.iref.e.1"></div> 857 884 <div id="rfc.iref.h.1"></div> 858 <p id="rfc.section.4. 1.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation,859 whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expir iation time is available.885 <p id="rfc.section.4.2.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, 886 whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiration time is available. 860 887 </p> 861 888 <div id="rfc.iref.a.1"></div> 862 <p id="rfc.section.4. 1.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.863 </p> 864 <p id="rfc.section.4. 1.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,889 <p id="rfc.section.4.2.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server. 890 </p> 891 <p id="rfc.section.4.2.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, 865 892 thereby improving efficiency. 866 893 </p> 867 <p id="rfc.section.4. 1.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,894 <p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, 868 895 using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 7.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section 7.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation 869 896 is not likely to change in a semantically significant way before the expiration time is reached. 870 897 </p> 871 <p id="rfc.section.4. 1.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past898 <p id="rfc.section.4.2.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past 872 899 to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing 873 it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4. 1.4</a>).874 </p> 875 <p id="rfc.section.4. 1.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine876 an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a>).900 it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>). 901 </p> 902 <p id="rfc.section.4.2.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine 903 an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>). 877 904 </p> 878 905 <div id="rfc.figure.u.2"></div> 879 906 <p>The calculation to determine if a response is fresh is:</p><pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 880 </pre><p id="rfc.section.4. 1.p.9">freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a>; current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>.881 </p> 882 <p id="rfc.section.4. 1.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the907 </pre><p id="rfc.section.4.2.p.9">freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.2.1</a>; current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>. 908 </p> 909 <p id="rfc.section.4.2.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the 883 910 corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 884 911 </p> 885 <p id="rfc.section.4. 1.p.11">When calculating freshness, to avoid common problems in date parsing:</p>886 <p id="rfc.section.4. 1.p.12"></p>912 <p id="rfc.section.4.2.p.11">When calculating freshness, to avoid common problems in date parsing:</p> 913 <p id="rfc.section.4.2.p.12"></p> 887 914 <ul> 888 915 <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively. … … 895 922 </li> 896 923 </ul> 897 <p id="rfc.section.4. 1.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload924 <p id="rfc.section.4.2.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload 898 925 a resource. See <a href="#history.lists" title="History Lists">Section 8</a> for an explanation of the difference between caches and history mechanisms. 899 926 </p> 900 <h3 id="rfc.section.4. 1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>901 <p id="rfc.section.4. 1.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>927 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3> 928 <p id="rfc.section.4.2.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p> 902 929 <ul> 903 930 <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section 7.2.2.9</a>) is present, use its value, or … … 907 934 <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 7.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or 908 935 </li> 909 <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a>.910 </li> 911 </ul> 912 <p id="rfc.section.4. 1.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>913 <p id="rfc.section.4. 1.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged936 <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>. 937 </li> 938 </ul> 939 <p id="rfc.section.4.2.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p> 940 <p id="rfc.section.4.2.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged 914 941 to consider responses that have invalid freshness information to be stale. 915 942 </p> 916 <h3 id="rfc.section.4. 1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>917 <p id="rfc.section.4. 1.2.p.1">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field943 <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3> 944 <p id="rfc.section.4.2.2.p.1">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field 918 945 values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case 919 946 constraints on their results. 920 947 </p> 921 <p id="rfc.section.4. 1.2.p.2">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements948 <p id="rfc.section.4.2.2.p.2">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements 922 949 in <a href="#response.cacheability" title="Storing Responses in Caches">Section 3</a>, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are 923 950 defined as cacheable, and responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a 924 951 "public" response cache directive). 925 952 </p> 926 <p id="rfc.section.4. 1.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that953 <p id="rfc.section.4.2.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that 927 954 time. A typical setting of this fraction might be 10%. 928 955 </p> 929 <p id="rfc.section.4. 1.2.p.4">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already956 <p id="rfc.section.4.2.2.p.4">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already 930 957 present. 931 958 </p> 932 <div class="note" id="rfc.section.4. 1.2.p.5">959 <div class="note" id="rfc.section.4.2.2.p.5"> 933 960 <p><b>Note:</b> <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, 934 961 this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control: … … 936 963 </p> 937 964 </div> 938 <h3 id="rfc.section.4. 1.3"><a href="#rfc.section.4.1.3">4.1.3</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>939 <p id="rfc.section.4. 1.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is965 <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3> 966 <p id="rfc.section.4.2.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is 940 967 the cache's estimate of the number of seconds since the response was generated or validated by the origin server. In essence, 941 968 the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin 942 969 server, plus the amount of time it has been in transit along network paths. 943 970 </p> 944 <p id="rfc.section.4. 1.3.p.2">The following data is used for the age calculation:</p>945 <p id="rfc.section.4. 1.3.p.3"><dfn>age_value</dfn>971 <p id="rfc.section.4.2.3.p.2">The following data is used for the age calculation:</p> 972 <p id="rfc.section.4.2.3.p.3"><dfn>age_value</dfn> 946 973 </p> 947 974 <ul class="empty"> … … 949 976 </li> 950 977 </ul> 951 <p id="rfc.section.4. 1.3.p.4"><dfn>date_value</dfn>978 <p id="rfc.section.4.2.3.p.4"><dfn>date_value</dfn> 952 979 </p> 953 980 <ul class="empty"> 954 <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.955 </li> 956 </ul> 957 <p id="rfc.section.4. 1.3.p.5"><dfn>now</dfn>981 <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 982 </li> 983 </ul> 984 <p id="rfc.section.4.2.3.p.5"><dfn>now</dfn> 958 985 </p> 959 986 <ul class="empty"> … … 961 988 </li> 962 989 </ul> 963 <p id="rfc.section.4. 1.3.p.6"><dfn>request_time</dfn>990 <p id="rfc.section.4.2.3.p.6"><dfn>request_time</dfn> 964 991 </p> 965 992 <ul class="empty"> 966 993 <li>The current value of the clock at the host at the time the request resulting in the stored response was made.</li> 967 994 </ul> 968 <p id="rfc.section.4. 1.3.p.7"><dfn>response_time</dfn>995 <p id="rfc.section.4.2.3.p.7"><dfn>response_time</dfn> 969 996 </p> 970 997 <ul class="empty"> 971 998 <li>The current value of the clock at the host at the time the response was received.</li> 972 999 </ul> 973 <p id="rfc.section.4. 1.3.p.8">A response's age can be calculated in two entirely independent ways: </p>1000 <p id="rfc.section.4.2.3.p.8">A response's age can be calculated in two entirely independent ways: </p> 974 1001 <ol> 975 1002 <li>the "apparent_age": response_time minus date_value, if the local clock is reasonably well synchronized to the origin server's … … 985 1012 </pre><div id="rfc.figure.u.4"></div> 986 1013 <p>These are combined as</p><pre class="text"> corrected_initial_age = max(apparent_age, corrected_age_value); 987 </pre><p id="rfc.section.4. 1.3.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.988 </p> 989 <p id="rfc.section.4. 1.3.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response1014 </pre><p id="rfc.section.4.2.3.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age. 1015 </p> 1016 <p id="rfc.section.4.2.3.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 990 1017 was last validated by the origin server to the corrected_initial_age. 991 1018 </p> 992 1019 <div id="rfc.figure.u.5"></div><pre class="text"> resident_time = now - response_time; 993 1020 current_age = corrected_initial_age + resident_time; 994 </pre><h3 id="rfc.section.4. 1.4"><a href="#rfc.section.4.1.4">4.1.4</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>995 <p id="rfc.section.4. 1.4.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but996 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section 4. 1</a>.997 </p> 998 <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" cache1021 </pre><h3 id="rfc.section.4.2.4"><a href="#rfc.section.4.2.4">4.2.4</a> <a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3> 1022 <p id="rfc.section.4.2.4.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but 1023 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section 4.2</a>. 1024 </p> 1025 <p id="rfc.section.4.2.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 999 1026 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 1000 1027 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>). 1001 1028 </p> 1002 <p id="rfc.section.4. 1.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)1029 <p id="rfc.section.4.2.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 1003 1030 or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 1004 1031 </p> 1005 <p id="rfc.section.4. 1.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.1032 <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected. 1006 1033 </p> 1007 1034 <div id="rfc.iref.f.3"></div> 1008 <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 ought not attempt to validate a response simply because1035 <p id="rfc.section.4.2.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 ought not attempt to validate a response simply because 1009 1036 that response became stale in transit. 1010 1037 </p> 1011 <h2 id="rfc.section.4. 2"><a href="#rfc.section.4.2">4.2</a> <a id="validation.model" href="#validation.model">Validation</a></h2>1012 <p id="rfc.section.4. 2.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not1013 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to1038 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="validation.model" href="#validation.model">Validation</a></h2> 1039 <p id="rfc.section.4.3.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 1040 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 1014 1041 update it. This process is known as "validating" or "revalidating" the stored response. 1015 1042 </p> 1016 1043 <div id="rfc.iref.v.1"></div> 1017 <p id="rfc.section.4. 2.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of1044 <p id="rfc.section.4.3.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of 1018 1045 the resource. 1019 1046 </p> 1020 <p id="rfc.section.4. 2.p.3">One such validator is the <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field, whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.3</a>) stored response, if available.1021 </p> 1022 <p id="rfc.section.4. 2.p.4">Another is the <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field, whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses1047 <p id="rfc.section.4.3.p.3">One such validator is the <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field, whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) stored response, if available. 1048 </p> 1049 <p id="rfc.section.4.3.p.4">Another is the <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field, whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses 1023 1050 contains only partial content, the cache ought not include its entity-tag in the If-None-Match header field unless the request 1024 1051 is for a range that would be fully satisfied by that stored response. 1025 1052 </p> 1026 <p id="rfc.section.4. 2.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p>1027 <p id="rfc.section.4. 2.p.6"></p>1053 <p id="rfc.section.4.3.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p> 1054 <p id="rfc.section.4.3.p.6"></p> 1028 1055 <ul> 1029 <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4. 2.1</a>.1056 <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.1</a>. 1030 1057 </li> 1031 1058 <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request … … 1033 1060 </li> 1034 1061 <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as 1035 if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4. 1.4</a>).1036 </li> 1037 </ul> 1038 <h3 id="rfc.section.4. 2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>1039 <p id="rfc.section.4. 2.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response1062 if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.2.4</a>). 1063 </li> 1064 </ul> 1065 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3> 1066 <p id="rfc.section.4.3.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response 1040 1067 and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response. 1041 1068 </p> 1042 1069 <div id="rfc.iref.s.3"></div> 1043 <p id="rfc.section.4. 2.1.p.2">The stored response to update is identified by using the first match (if any) of: </p>1070 <p id="rfc.section.4.3.1.p.2">The stored response to update is identified by using the first match (if any) of: </p> 1044 1071 <ul> 1045 1072 <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 … … 1054 1081 </li> 1055 1082 </ul> 1056 <p id="rfc.section.4. 2.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:1083 <p id="rfc.section.4.3.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 1057 1084 </p> 1058 1085 <ul> … … 1064 1091 </li> 1065 1092 </ul> 1066 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2>1067 <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original1068 request (i.e., that associated with the stored response), and the presented request.1069 </p>1070 <p id="rfc.section.4.3.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed1071 to those in the second request by applying any of the following:1072 </p>1073 <ul>1074 <li>adding or removing whitespace, where allowed in the header field's syntax</li>1075 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>)1076 </li>1077 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification1078 (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)1079 </li>1080 </ul>1081 <p id="rfc.section.4.3.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request1082 if it is also absent there.1083 </p>1084 <p id="rfc.section.4.3.p.4">A <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.1085 </p>1086 <p id="rfc.section.4.3.p.5">The stored response with matching selecting header fields is known as the selected response.</p>1087 <p id="rfc.section.4.3.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will1088 need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 4</a>.1089 </p>1090 <p id="rfc.section.4.3.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin1091 server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section 4.2</a>) request.1092 </p>1093 1093 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="head.effects" href="#head.effects">Updating Caches with HEAD Responses</a></h1> 1094 1094 <p id="rfc.section.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks 1095 1095 a body. This property of HEAD responses is used to both invalidate and update cached GET responses. 1096 1096 </p> 1097 <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.1098 </p> 1099 <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules:1097 <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1098 </p> 1099 <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 1100 1100 </p> 1101 1101 <ul> … … 1131 1131 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.age" href="#header.age">Age</a></h2> 1132 1132 <p id="rfc.section.7.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully 1133 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 4. 1.3</a>.1133 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>. 1134 1134 </p> 1135 1135 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#header.age" class="smpl">Age</a> = <a href="#delta-seconds" class="smpl">delta-seconds</a> … … 1355 1355 <div id="rfc.iref.e.2"></div> 1356 1356 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1357 <p id="rfc.section.7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section 4. 1</a> for further discussion of the freshness model.1357 <p id="rfc.section.7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section 4.2</a> for further discussion of the freshness model. 1358 1358 </p> 1359 1359 <p id="rfc.section.7.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 … … 1502 1502 retrieved earlier in a session. 1503 1503 </p> 1504 <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section 4. 1</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if1504 <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section 4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if 1505 1505 it has expired. 1506 1506 </p> … … 1863 1863 </p> 1864 1864 <p id="rfc.section.A.p.3">New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate 1865 heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4. 1.2</a>)1865 heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a>) 1866 1866 </p> 1867 1867 <p id="rfc.section.A.p.4">The algorithm for calculating age is now less conservative. Caches are now required to handle dates with timezones as if they're 1868 invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section 4. 1.3</a>)1869 </p> 1870 <p id="rfc.section.A.p.5">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section 4. 2</a>)1868 invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section 4.2.3</a>) 1869 </p> 1870 <p id="rfc.section.A.p.5">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section 4.3</a>) 1871 1871 </p> 1872 1872 <p id="rfc.section.A.p.6">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now 1873 explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4. 3</a>)1873 explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.1</a>) 1874 1874 </p> 1875 1875 <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>) … … 2045 2045 </li> 2046 2046 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 2047 <li>age <a href="#rfc.iref.a.1">4. 1</a></li>2048 <li>Age header field <a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4. 1.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li>2047 <li>age <a href="#rfc.iref.a.1">4.2</a></li> 2048 <li>Age header field <a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li> 2049 2049 </ul> 2050 2050 </li> … … 2061 2061 </li> 2062 2062 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 2063 <li>Expires header field <a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4. 1</a>, <a href="#rfc.xref.header.expires.3">4.1.1</a>, <a href="#rfc.iref.e.2"><b>7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>2064 <li>explicit expiration time <a href="#rfc.iref.e.1">4. 1</a></li>2063 <li>Expires header field <a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li> 2064 <li>explicit expiration time <a href="#rfc.iref.e.1">4.2</a></li> 2065 2065 </ul> 2066 2066 </li> 2067 2067 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 2068 <li>first-hand <a href="#rfc.iref.f.3">4. 1.4</a></li>2069 <li>fresh <a href="#rfc.iref.f.1">4. 1</a></li>2070 <li>freshness lifetime <a href="#rfc.iref.f.2">4. 1</a></li>2068 <li>first-hand <a href="#rfc.iref.f.3">4.2.4</a></li> 2069 <li>fresh <a href="#rfc.iref.f.1">4.2</a></li> 2070 <li>freshness lifetime <a href="#rfc.iref.f.2">4.2</a></li> 2071 2071 </ul> 2072 2072 </li> … … 2093 2093 </li> 2094 2094 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 2095 <li>heuristic expiration time <a href="#rfc.iref.h.1">4. 1</a></li>2095 <li>heuristic expiration time <a href="#rfc.iref.h.1">4.2</a></li> 2096 2096 </ul> 2097 2097 </li> … … 2114 2114 </li> 2115 2115 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2116 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4. 3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>2116 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul> 2117 2117 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.21">C</a></li> 2118 2118 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 2119 2119 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.20">B</a></li> 2120 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.5">4. 3</a>, <a href="#rfc.xref.Part1.15">B</a></li>2120 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.15">B</a></li> 2121 2121 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.14">B</a></li> 2122 2122 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a></li> … … 2128 2128 </ul> 2129 2129 </li> 2130 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1 .3</a>, <a href="#rfc.xref.Part2.5">4.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>2130 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul> 2131 2131 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">6</a></li> 2132 2132 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.2">2</a></li> 2133 2133 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.9">B</a></li> 2134 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2. 4">4.1.3</a></li>2135 <li><em>Section 7.1.4</em> <a href="#rfc.xref.Part2. 5">4.3</a></li>2134 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.5">4.2.3</a></li> 2135 <li><em>Section 7.1.4</em> <a href="#rfc.xref.Part2.4">4.1</a></li> 2136 2136 </ul> 2137 2137 </li> 2138 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4. 1.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">4.2.1</a>, <a href="#Part4"><b>12.1</b></a><ul>2139 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.3">4. 2.1</a></li>2140 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4. 1.2</a></li>2138 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#Part4"><b>12.1</b></a><ul> 2139 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.3">4.3.1</a></li> 2140 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4.2.2</a></li> 2141 2141 </ul> 2142 2142 </li> … … 2157 2157 </li> 2158 2158 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 2159 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4. 1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>2159 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>12.2</b></a></li> 2160 2160 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li> 2161 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4. 1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>2162 <li><em>Section 13.9</em> <a href="#rfc.xref.RFC2616.1">4. 1.2</a></li>2161 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul> 2162 <li><em>Section 13.9</em> <a href="#rfc.xref.RFC2616.1">4.2.2</a></li> 2163 2163 </ul> 2164 2164 </li> … … 2182 2182 <li>s-maxage (cache directive) <a href="#rfc.iref.s.4"><b>7.2.2.9</b></a></li> 2183 2183 <li>shared cache <a href="#rfc.iref.s.1">1</a></li> 2184 <li>stale <a href="#rfc.iref.s.2">4. 1</a></li>2185 <li>strong validator <a href="#rfc.iref.s.3">4. 2.1</a></li>2184 <li>stale <a href="#rfc.iref.s.2">4.2</a></li> 2185 <li>strong validator <a href="#rfc.iref.s.3">4.3.1</a></li> 2186 2186 </ul> 2187 2187 </li> 2188 2188 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2189 <li>validator <a href="#rfc.iref.v.1">4. 2</a></li>2189 <li>validator <a href="#rfc.iref.v.1">4.3</a></li> 2190 2190 </ul> 2191 2191 </li> 2192 2192 <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul> 2193 <li>Warning header field <a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4. 1.4</a>, <a href="#rfc.xref.header.warning.3">4.2.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>2193 <li>Warning header field <a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li> 2194 2194 </ul> 2195 2195 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2369 r2371 452 452 </t> 453 453 454 <section anchor="caching.negotiated.responses" 455 title="Calculating Secondary Keys with Vary"> 456 <t> 457 When a cache receives a request that can be satisfied by a stored response 458 that has a <x:ref>Vary</x:ref> header field (&header-vary;), 459 it &MUST-NOT; use that response unless all of the selecting header fields 460 nominated by the Vary header field match in both the original request 461 (i.e., that associated with the stored response), and the presented 462 request. 463 </t> 464 <t> 465 The selecting header fields from two requests are defined to match if and 466 only if those in the first request can be transformed to those in the 467 second request by applying any of the following: 468 <list style="symbols"> 469 <t> 470 adding or removing whitespace, where allowed in the header field's 471 syntax 472 </t> 473 <t> 474 combining multiple header fields with the same field name 475 (see &header-fields;) 476 </t> 477 <t> 478 normalizing both header field values in a way that is known to have 479 identical semantics, according to the header field's specification 480 (e.g., re-ordering field values when order is not significant; 481 case-normalization, where values are defined to be case-insensitive) 482 </t> 483 </list> 484 </t> 485 <t> 486 If (after any normalization that might take place) a header field is absent 487 from a request, it can only match another request if it is also absent 488 there. 489 </t> 490 <t> 491 A <x:ref>Vary</x:ref> header field-value of "*" always fails to match. 492 </t> 493 <t> 494 The stored response with matching selecting header fields is known as the 495 selected response. 496 </t> 497 <t> 498 If multiple selected responses are available (potentially including 499 responses without a Vary header field), the cache will need to choose one to use. 500 When a selecting header field has a known mechanism for doing so (e.g., qvalues on 501 <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be 502 used to select preferred responses; of the remainder, the most recent 503 response (as determined by the <x:ref>Date</x:ref> header field) is used, as 504 per <xref target="constructing.responses.from.caches"/>. 505 </t> 506 <t> 507 If no selected response is available, the cache cannot satisfy the 508 presented request. Typically, it is forwarded to the origin server 509 in a (possibly conditional; see <xref target="validation.model"/>) request. 510 </t> 511 </section> 454 512 455 513 <section anchor="expiration.model" title="Freshness"> … … 470 528 server intends that a stored response can no longer be used by a cache 471 529 without further validation, whereas a <x:dfn>heuristic expiration 472 time</x:dfn> is assigned by a cache when no explicit expir iation time is530 time</x:dfn> is assigned by a cache when no explicit expiration time is 473 531 available. 474 532 </t> … … 878 936 </section> 879 937 880 </section>881 882 <section anchor="caching.negotiated.responses"883 title="Calculating Secondary Keys with Vary">884 <t>885 When a cache receives a request that can be satisfied by a stored response886 that has a <x:ref>Vary</x:ref> header field (&header-vary;),887 it &MUST-NOT; use that response unless all of the selecting header fields888 nominated by the Vary header field match in both the original request889 (i.e., that associated with the stored response), and the presented890 request.891 </t>892 <t>893 The selecting header fields from two requests are defined to match if and894 only if those in the first request can be transformed to those in the895 second request by applying any of the following:896 <list style="symbols">897 <t>898 adding or removing whitespace, where allowed in the header field's899 syntax900 </t>901 <t>902 combining multiple header fields with the same field name903 (see &header-fields;)904 </t>905 <t>906 normalizing both header field values in a way that is known to have907 identical semantics, according to the header field's specification908 (e.g., re-ordering field values when order is not significant;909 case-normalization, where values are defined to be case-insensitive)910 </t>911 </list>912 </t>913 <t>914 If (after any normalization that might take place) a header field is absent915 from a request, it can only match another request if it is also absent916 there.917 </t>918 <t>919 A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.920 </t>921 <t>922 The stored response with matching selecting header fields is known as the923 selected response.924 </t>925 <t>926 If multiple selected responses are available (potentially including927 responses without a Vary header field), the cache will need to choose one to use.928 When a selecting header field has a known mechanism for doing so (e.g., qvalues on929 <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be930 used to select preferred responses; of the remainder, the most recent931 response (as determined by the <x:ref>Date</x:ref> header field) is used, as932 per <xref target="constructing.responses.from.caches"/>.933 </t>934 <t>935 If no selected response is available, the cache cannot satisfy the936 presented request. Typically, it is forwarded to the origin server937 in a (possibly conditional; see <xref target="validation.model"/>) request.938 </t>939 938 </section> 940 939
Note: See TracChangeset
for help on using the changeset viewer.