Changeset 2239 for draft-ietf-httpbis/latest
- Timestamp:
- 07/05/13 07:14:23 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r2238 r2239 578 578 <ul class="toc"> 579 579 <li><a href="#rfc.section.1">1.</a> <a href="#caching">Introduction</a><ul> 580 <li><a href="#rfc.section.1.1">1.1</a> <a href="#intro.terminology">Terminology</a></li> 581 <li><a href="#rfc.section.1.2">1.2</a> <a href="#conformance">Conformance and Error Handling</a></li> 582 <li><a href="#rfc.section.1.3">1.3</a> <a href="#notation">Syntax Notation</a><ul> 583 <li><a href="#rfc.section.1.3.1">1.3.1</a> <a href="#delta-seconds">Delta Seconds</a></li> 580 <li><a href="#rfc.section.1.1">1.1</a> <a href="#conformance">Conformance and Error Handling</a></li> 581 <li><a href="#rfc.section.1.2">1.2</a> <a href="#notation">Syntax Notation</a><ul> 582 <li><a href="#rfc.section.1.2.1">1.2.1</a> <a href="#delta-seconds">Delta Seconds</a></li> 584 583 </ul> 585 584 </li> … … 689 688 requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel. 690 689 </p> 691 <p id="rfc.section.1.p.3">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current 690 <div id="rfc.iref.s.1"></div> 691 <div id="rfc.iref.p.1"></div> 692 <div id="shared.and.non-shared.caches"> 693 <p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as 694 a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user. 695 </p> 696 </div> 697 <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 692 698 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 remains 693 699 valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When 694 700 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 (xref target="serving.stale.responses" />). 695 701 </p> 696 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.terminology" href="#intro.terminology">Terminology</a></h2> 697 <p id="rfc.section.1.1.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, HTTP caching.</p> 698 <p id="rfc.section.1.1.p.2"> <span id="rfc.iref.c.2"></span> <dfn>cache</dfn> 699 </p> 700 <ul class="empty"> 701 <li>A conformant implementation of an HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define 702 conformance for HTTP/1.0 caches. 703 </li> 704 </ul> 705 <div id="shared.and.non-shared.caches"> 706 <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.s.1"></span> <dfn>shared cache</dfn> 707 </p> 708 <ul class="empty"> 709 <li>A cache that stores responses to be reused by more than one user; usually (but not always) deployed as part of an intermediary.</li> 710 </ul> 711 </div> 712 <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.p.1"></span> <dfn>private cache</dfn> 713 </p> 714 <ul class="empty"> 715 <li>A cache that is dedicated to a single user.</li> 716 </ul> 717 <p id="rfc.section.1.1.p.5"> <span id="rfc.iref.c.3"></span> <dfn>cacheable</dfn> 718 </p> 719 <ul class="empty"> 720 <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 721 Even when a response is cacheable, there might be additional constraints on whether a cache can use the stored copy to satisfy 722 a particular request. 723 </li> 724 </ul> 725 <p id="rfc.section.1.1.p.6"> <span id="rfc.iref.e.1"></span> <dfn>explicit expiration time</dfn> 726 </p> 727 <ul class="empty"> 728 <li>The time at which the origin server intends that a stored response no longer be used by a cache without further validation.</li> 729 </ul> 730 <p id="rfc.section.1.1.p.7"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 731 </p> 732 <ul class="empty"> 733 <li>An expiration time assigned by a cache when no explicit expiration time is available.</li> 734 </ul> 735 <p id="rfc.section.1.1.p.8"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 736 </p> 737 <ul class="empty"> 738 <li>The time since a response was sent by, or successfully validated with, the origin server.</li> 739 </ul> 740 <p id="rfc.section.1.1.p.9"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 741 </p> 742 <ul class="empty"> 743 <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li> 744 </ul> 745 <p id="rfc.section.1.1.p.10"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 746 </p> 747 <ul class="empty"> 748 <li>The length of time between the generation of a response and its expiration time (either explicit or heuristic).</li> 749 </ul> 750 <p id="rfc.section.1.1.p.11"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 751 </p> 752 <ul class="empty"> 753 <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li> 754 </ul> 755 <p id="rfc.section.1.1.p.12"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> 756 </p> 757 <ul class="empty"> 758 <li>A response is stale if its age has passed its freshness lifetime.</li> 759 </ul> 760 <p id="rfc.section.1.1.p.13"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> 761 </p> 762 <ul class="empty"> 763 <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. . 764 </li> 765 </ul> 766 <p id="rfc.section.1.1.p.14"> <span id="rfc.iref.s.3"></span> <span id="rfc.iref.v.2"></span> <dfn>strong validator</dfn> 767 </p> 768 <ul class="empty"> 769 <li>A validator that is defined by the origin server such that its current value will change if the representation data changes. 770 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.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></li> 771 </ul> 772 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="conformance" href="#conformance">Conformance and Error Handling</a></h2> 773 <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 702 <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> 703 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 774 704 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 775 705 </p> 776 <p id="rfc.section.1. 2.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.777 </p> 778 <h2 id="rfc.section.1. 3"><a href="#rfc.section.1.3">1.3</a> <a id="notation" href="#notation">Syntax Notation</a></h2>779 <p id="rfc.section.1. 3.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded.780 </p> 781 <h3 id="rfc.section.1. 3.1"><a href="#rfc.section.1.3.1">1.3.1</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3>782 <p id="rfc.section.1. 3.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>706 <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 707 </p> 708 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 709 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF with the list rule expanded. 710 </p> 711 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3> 712 <p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p> 783 713 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> 784 </pre><p id="rfc.section.1. 3.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of714 </pre><p id="rfc.section.1.2.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of 785 715 its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648. 786 716 </p> 787 <div id="rfc.iref.c. 4"></div>788 <div id="rfc.iref.c. 5"></div>717 <div id="rfc.iref.c.2"></div> 718 <div id="rfc.iref.c.3"></div> 789 719 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Overview of Cache Operation</a></h1> 790 720 <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when … … 797 727 use as a cache key. 798 728 </p> 729 <div id="rfc.iref.c.4"></div> 799 730 <p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching 800 731 responses to GET, many implementations simply decline other methods and use only the URI as the primary cache key. … … 910 841 <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. 911 842 </p> 843 <div id="rfc.iref.f.1"></div> 844 <div id="rfc.iref.s.2"></div> 912 845 <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> 913 <p id="rfc.section.4.1.p.1">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, 846 <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. 847 </p> 848 <div id="rfc.iref.f.2"></div> 849 <div id="rfc.iref.e.1"></div> 850 <div id="rfc.iref.h.1"></div> 851 <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, 852 whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiriation time is available. 853 </p> 854 <div id="rfc.iref.a.1"></div> 855 <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. 856 </p> 857 <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, 914 858 thereby improving efficiency. 915 859 </p> 916 <p id="rfc.section.4.1.p. 2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,860 <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, 917 861 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 918 862 is not likely to change in a semantically significant way before the expiration time is reached. 919 863 </p> 920 <p id="rfc.section.4.1.p. 3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past864 <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 past 921 865 to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing 922 866 it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 4.1.4</a>). 923 867 </p> 924 <p id="rfc.section.4.1.p. 4">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine868 <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 determine 925 869 an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a>). 926 870 </p> 927 871 <div id="rfc.figure.u.2"></div> 928 872 <p>The calculation to determine if a response is fresh is:</p><pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 929 </pre><p id="rfc.section.4.1.p. 6">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>.930 </p> 931 <p id="rfc.section.4.1.p. 7">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the873 </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>. 874 </p> 875 <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 the 932 876 corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section 7.2.1</a>). 933 877 </p> 934 <p id="rfc.section.4.1.p. 8">When calculating freshness, to avoid common problems in date parsing:</p>935 <p id="rfc.section.4.1.p. 9"> </p>878 <p id="rfc.section.4.1.p.11">When calculating freshness, to avoid common problems in date parsing:</p> 879 <p id="rfc.section.4.1.p.12"> </p> 936 880 <ul> 937 881 <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. … … 944 888 </li> 945 889 </ul> 946 <p id="rfc.section.4.1.p.1 0">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload890 <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 reload 947 891 a resource. See <a href="#history.lists" title="History Lists">Section 8</a> for an explanation of the difference between caches and history mechanisms. 948 892 </p> … … 973 917 "public" response cache directive). 974 918 </p> 975 <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. 2"><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 that919 <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 that 976 920 time. A typical setting of this fraction might be 10%. 977 921 </p> … … 1055 999 <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. 1056 1000 </p> 1057 <p id="rfc.section.4.1.4.p.5">note that if a cache receives a first-hand response (either 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 1001 <div id="rfc.iref.f.3"></div> 1002 <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 1058 1003 can forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because 1059 1004 that response became stale in transit. … … 1061 1006 <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> 1062 1007 <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 not 1063 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. 3"><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 to1008 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 to 1064 1009 update it. This process is known as "validating" or "revalidating" the stored response. 1065 1010 </p> 1066 <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds an <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. 1067 </p> 1068 <p id="rfc.section.4.2.p.3">Additionally, a cache can add an <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 1011 <div id="rfc.iref.v.1"></div> 1012 <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 of 1013 the resource. 1014 </p> 1015 <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. 1016 </p> 1017 <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 responses 1069 1018 contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request 1070 1019 is for a range that would be fully satisfied by that stored response. 1071 1020 </p> 1072 <p id="rfc.section.4.2.p. 4">Cache handling of a response to a conditional request is dependent upon its status code:</p>1073 <p id="rfc.section.4.2.p. 5"> </p>1021 <p id="rfc.section.4.2.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p> 1022 <p id="rfc.section.4.2.p.6"> </p> 1074 1023 <ul> 1075 1024 <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>. … … 1086 1035 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. 1087 1036 </p> 1037 <div id="rfc.iref.s.3"></div> 1088 1038 <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> 1089 1039 <ul> 1090 <li>If the new response contains a strong validator, then that strong validator identifies the selected representation for update. 1091 All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same 1092 strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses. 1040 <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 1041 strong validator are selected. If none of the stored responses contain the same strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses. 1093 1042 </li> 1094 1043 <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then … … 1180 1129 </p> 1181 1130 <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> 1182 </pre><p id="rfc.section.7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>).1131 </pre><p id="rfc.section.7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>). 1183 1132 </p> 1184 1133 <p id="rfc.section.7.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not 1185 1134 true, since HTTP/1.0 caches might not implement the Age header field. 1186 1135 </p> 1187 <div id="rfc.iref.c. 6"></div>1136 <div id="rfc.iref.c.5"></div> 1188 1137 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 1189 1138 <p id="rfc.section.7.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives … … 1214 1163 <p id="rfc.section.7.2.1.1.p.1">Argument syntax: </p> 1215 1164 <ul class="empty"> 1216 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>)1165 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1217 1166 </li> 1218 1167 </ul> … … 1227 1176 <p id="rfc.section.7.2.1.2.p.1">Argument syntax: </p> 1228 1177 <ul class="empty"> 1229 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>)1178 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1230 1179 </li> 1231 1180 </ul> … … 1241 1190 <p id="rfc.section.7.2.1.3.p.1">Argument syntax: </p> 1242 1191 <ul class="empty"> 1243 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>)1192 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1244 1193 </li> 1245 1194 </ul> … … 1351 1300 <p id="rfc.section.7.2.2.8.p.1">Argument syntax: </p> 1352 1301 <ul class="empty"> 1353 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>)1302 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1354 1303 </li> 1355 1304 </ul> … … 1363 1312 <p id="rfc.section.7.2.2.9.p.1">Argument syntax: </p> 1364 1313 <ul class="empty"> 1365 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1. 3.1</a>)1314 <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section 1.2.1</a>) 1366 1315 </li> 1367 1316 </ul> … … 1522 1471 of its meaning. 1523 1472 </p> 1524 <div id="rfc.iref.5 2"></div>1473 <div id="rfc.iref.50"></div> 1525 1474 <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="warn.110" href="#warn.110">110 Response is Stale</a></h3> 1526 1475 <p id="rfc.section.7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale. 1527 1476 </p> 1528 <div id="rfc.iref.5 2"></div>1477 <div id="rfc.iref.50"></div> 1529 1478 <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3> 1530 1479 <p id="rfc.section.7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach 1531 1480 the server. 1532 1481 </p> 1533 <div id="rfc.iref.5 2"></div>1482 <div id="rfc.iref.50"></div> 1534 1483 <h3 id="rfc.section.7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a> <a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3> 1535 1484 <p id="rfc.section.7.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time. 1536 1485 </p> 1537 <div id="rfc.iref.5 2"></div>1486 <div id="rfc.iref.50"></div> 1538 1487 <h3 id="rfc.section.7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a> <a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3> 1539 1488 <p id="rfc.section.7.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 1540 1489 24 hours. 1541 1490 </p> 1542 <div id="rfc.iref.5 2"></div>1491 <div id="rfc.iref.50"></div> 1543 1492 <h3 id="rfc.section.7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a> <a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3> 1544 1493 <p id="rfc.section.7.5.5.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user. 1545 1494 </p> 1546 <div id="rfc.iref.5 2"></div>1495 <div id="rfc.iref.50"></div> 1547 1496 <h3 id="rfc.section.7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a> <a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3> 1548 1497 <p id="rfc.section.7.5.6.p.1"> <em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, 1549 1498 or modifying the representation data, unless this Warning code already appears in the response. 1550 1499 </p> 1551 <div id="rfc.iref.5 2"></div>1500 <div id="rfc.iref.50"></div> 1552 1501 <h3 id="rfc.section.7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a> <a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3> 1553 1502 <p id="rfc.section.7.5.7.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action. … … 2060 2009 <ul class="ind"> 2061 2010 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 2062 <li>110 Response is Stale (warn code) <a href="#rfc.iref.5 2"><b>7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2</a></li>2063 <li>111 Revalidation Failed (warn code) <a href="#rfc.iref.5 2"><b>7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2</a></li>2064 <li>112 Disconnected Operation (warn code) <a href="#rfc.iref.5 2"><b>7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2</a></li>2065 <li>113 Heuristic Expiration (warn code) <a href="#rfc.iref.5 2"><b>7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2</a></li>2066 <li>199 Miscellaneous Warning (warn code) <a href="#rfc.iref.5 2"><b>7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2</a></li>2011 <li>110 Response is Stale (warn code) <a href="#rfc.iref.50"><b>7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2</a></li> 2012 <li>111 Revalidation Failed (warn code) <a href="#rfc.iref.50"><b>7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2</a></li> 2013 <li>112 Disconnected Operation (warn code) <a href="#rfc.iref.50"><b>7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2</a></li> 2014 <li>113 Heuristic Expiration (warn code) <a href="#rfc.iref.50"><b>7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2</a></li> 2015 <li>199 Miscellaneous Warning (warn code) <a href="#rfc.iref.50"><b>7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2</a></li> 2067 2016 </ul> 2068 2017 </li> 2069 2018 <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> 2070 <li>214 Transformation Applied (warn code) <a href="#rfc.iref.5 2"><b>7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2</a></li>2071 <li>299 Miscellaneous Persistent Warning (warn code) <a href="#rfc.iref.5 2"><b>7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2</a></li>2019 <li>214 Transformation Applied (warn code) <a href="#rfc.iref.50"><b>7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2</a></li> 2020 <li>299 Miscellaneous Persistent Warning (warn code) <a href="#rfc.iref.50"><b>7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2</a></li> 2072 2021 </ul> 2073 2022 </li> 2074 2023 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 2075 <li>age <a href="#rfc.iref.a.1"> 1.1</a></li>2024 <li>age <a href="#rfc.iref.a.1">4.1</a></li> 2076 2025 <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> 2077 2026 </ul> … … 2082 2031 </li> 2083 2032 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 2084 <li>cache <a href="#rfc.iref.c.1">1</a>, <a href="#rfc.iref.c.2">1.1</a></li> 2085 <li>cache entry <a href="#rfc.iref.c.4">2</a></li> 2086 <li>cache key <a href="#rfc.iref.c.5">2</a></li> 2087 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.6"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a>, <a href="#rfc.xref.header.cache-control.4">A</a></li> 2088 <li>cacheable <a href="#rfc.iref.c.3">1.1</a></li> 2033 <li>cache <a href="#rfc.iref.c.1">1</a></li> 2034 <li>cache entry <a href="#rfc.iref.c.2">2</a></li> 2035 <li>cache key <a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li> 2036 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a>, <a href="#rfc.xref.header.cache-control.4">A</a></li> 2089 2037 </ul> 2090 2038 </li> 2091 2039 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 2092 2040 <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> 2093 <li>explicit expiration time <a href="#rfc.iref.e.1"> 1.1</a></li>2041 <li>explicit expiration time <a href="#rfc.iref.e.1">4.1</a></li> 2094 2042 </ul> 2095 2043 </li> 2096 2044 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 2097 <li>first-hand <a href="#rfc.iref.f. 1">1.1</a></li>2098 <li>fresh <a href="#rfc.iref.f. 3">1.1</a></li>2099 <li>freshness lifetime <a href="#rfc.iref.f.2"> 1.1</a></li>2045 <li>first-hand <a href="#rfc.iref.f.3">4.1.4</a></li> 2046 <li>fresh <a href="#rfc.iref.f.1">4.1</a></li> 2047 <li>freshness lifetime <a href="#rfc.iref.f.2">4.1</a></li> 2100 2048 </ul> 2101 2049 </li> … … 2106 2054 <li><tt>Cache-Control</tt> <a href="#rfc.iref.g.3"><b>7.2</b></a></li> 2107 2055 <li><tt>cache-directive</tt> <a href="#rfc.iref.g.4"><b>7.2</b></a></li> 2108 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.1"><b>1. 3.1</b></a></li>2056 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.1"><b>1.2.1</b></a></li> 2109 2057 <li><tt>Expires</tt> <a href="#rfc.iref.g.5"><b>7.3</b></a></li> 2110 2058 <li><tt>extension-pragma</tt> <a href="#rfc.iref.g.8"><b>7.4</b></a></li> … … 2122 2070 </li> 2123 2071 <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> 2124 <li>heuristic expiration time <a href="#rfc.iref.h.1"> 1.1</a></li>2072 <li>heuristic expiration time <a href="#rfc.iref.h.1">4.1</a></li> 2125 2073 </ul> 2126 2074 </li> … … 2143 2091 </li> 2144 2092 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2145 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1. 2</a>, <a href="#rfc.xref.Part1.2">1.3</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>2146 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1. 3</a>, <a href="#rfc.xref.Part1.21">C</a></li>2147 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.1">1. 2</a></li>2093 <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> 2094 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.21">C</a></li> 2095 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 2148 2096 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.20">B</a></li> 2149 2097 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.15">B</a></li> … … 2164 2112 </ul> 2165 2113 </li> 2166 <li><em>Part4</em> <a href="#rfc.xref.Part4.1"> 1.1</a>, <a href="#rfc.xref.Part4.2">4.1.2</a>, <a href="#rfc.xref.Part4.3">4.2</a>, <a href="#Part4"><b>12.1</b></a><ul>2167 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4. 1">1.1</a></li>2168 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4. 2">4.1.2</a></li>2114 <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> 2115 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.3">4.2.1</a></li> 2116 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">4.1.2</a></li> 2169 2117 </ul> 2170 2118 </li> … … 2179 2127 <li>Pragma header field <a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>7.4</b></a>, <a href="#rfc.xref.header.pragma.2">9.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li> 2180 2128 <li>private (cache directive) <a href="#rfc.iref.p.3"><b>7.2.2.6</b></a></li> 2181 <li>private cache <a href="#rfc.iref.p.1">1 .1</a></li>2129 <li>private cache <a href="#rfc.iref.p.1">1</a></li> 2182 2130 <li>proxy-revalidate (cache directive) <a href="#rfc.iref.p.4"><b>7.2.2.7</b></a></li> 2183 2131 <li>public (cache directive) <a href="#rfc.iref.p.2"><b>7.2.2.5</b></a></li> … … 2186 2134 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 2187 2135 <li><em>RFC1305</em> <a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li> 2188 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1. 2</a>, <a href="#RFC2119"><b>12.1</b></a></li>2136 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li> 2189 2137 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">4.1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul> 2190 2138 <li><em>Section 13.9</em> <a href="#rfc.xref.RFC2616.1">4.1.2</a></li> … … 2195 2143 </ul> 2196 2144 </li> 2197 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1. 3</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>2145 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul> 2198 2146 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">B</a></li> 2199 2147 </ul> … … 2209 2157 <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> 2210 2158 <li>s-maxage (cache directive) <a href="#rfc.iref.s.4"><b>7.2.2.9</b></a></li> 2211 <li>shared cache <a href="#rfc.iref.s.1">1 .1</a></li>2212 <li>stale <a href="#rfc.iref.s.2"> 1.1</a></li>2213 <li>strong validator <a href="#rfc.iref.s.3"> 1.1</a></li>2159 <li>shared cache <a href="#rfc.iref.s.1">1</a></li> 2160 <li>stale <a href="#rfc.iref.s.2">4.1</a></li> 2161 <li>strong validator <a href="#rfc.iref.s.3">4.2.1</a></li> 2214 2162 </ul> 2215 2163 </li> 2216 2164 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2217 <li>validator <a href="#rfc.iref.v.1">1.1</a><ul> 2218 <li>strong <a href="#rfc.iref.v.2">1.1</a></li> 2219 </ul> 2220 </li> 2165 <li>validator <a href="#rfc.iref.v.1">4.2</a></li> 2221 2166 </ul> 2222 2167 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2238 r2239 153 153 is acting as a tunnel. 154 154 </t> 155 <iref item="shared cache" /> 156 <iref item="private cache" /> 157 <t anchor="shared.and.non-shared.caches"> 158 A <x:dfn>shared cache</x:dfn> is a cache that stores responses to be reused 159 by more than one user; shared caches are usually (but not always) deployed 160 as a part of an intermediary. A <x:dfn>private cache</x:dfn>, in contrast, 161 is dedicated to a single user. 162 </t> 155 163 <t> 156 164 The goal of caching in HTTP/1.1 is to significantly improve performance … … 166 174 </t> 167 175 168 <section anchor="intro.terminology" title="Terminology">169 <t>170 This specification uses a number of terms to refer to the roles played by171 participants in, and objects of, HTTP caching.172 </t>173 <t>174 <iref item="cache" />175 <x:dfn>cache</x:dfn>176 <list>177 <t>A conformant implementation of an HTTP cache. Note that this implies178 an HTTP/1.1 cache; this specification does not define conformance179 for HTTP/1.0 caches.</t>180 </list>181 </t>182 <t anchor="shared.and.non-shared.caches">183 <iref item="shared cache" />184 <x:dfn>shared cache</x:dfn>185 <list>186 <t>A cache that stores responses to be reused by more than one user;187 usually (but not always) deployed as part of an intermediary.</t>188 </list>189 </t>190 <t>191 <iref item="private cache" />192 <x:dfn>private cache</x:dfn>193 <list>194 <t>A cache that is dedicated to a single user.</t>195 </list>196 </t>197 <t>198 <iref item="cacheable" />199 <x:dfn>cacheable</x:dfn>200 <list>201 <t>A response is cacheable if a cache is allowed to store a copy of the202 response message for use in answering subsequent requests. Even when a203 response is cacheable, there might be additional constraints on whether204 a cache can use the stored copy to satisfy a particular request.</t>205 </list>206 </t>207 <t>208 <iref item="explicit expiration time" />209 <x:dfn>explicit expiration time</x:dfn>210 <list>211 <t>The time at which the origin server intends that a stored response212 no longer be used by a cache without further validation.</t>213 </list>214 </t>215 <t>216 <iref item="heuristic expiration time" />217 <x:dfn>heuristic expiration time</x:dfn>218 <list>219 <t>An expiration time assigned by a cache when no explicit expiration220 time is available.</t>221 </list>222 </t>223 <t>224 <iref item="age" />225 <x:dfn>age</x:dfn>226 <list>227 <t>The time since a response was sent by, or successfully validated228 with, the origin server.</t>229 </list>230 </t>231 <t>232 <iref item="first-hand" />233 <x:dfn>first-hand</x:dfn>234 <list>235 <t>A response is first-hand if the freshness model is not in use; i.e.,236 its age is 0.</t>237 </list>238 </t>239 <t>240 <iref item="freshness lifetime" />241 <x:dfn>freshness lifetime</x:dfn>242 <list>243 <t>The length of time between the generation of a response and its244 expiration time (either explicit or heuristic).</t>245 </list>246 </t>247 <t>248 <iref item="fresh" />249 <x:dfn>fresh</x:dfn>250 <list>251 <t>A response is fresh if its age has not yet exceeded its freshness252 lifetime.</t>253 </list>254 </t>255 <t>256 <iref item="stale" />257 <x:dfn>stale</x:dfn>258 <list>259 <t>A response is stale if its age has passed its freshness lifetime.</t>260 </list>261 </t>262 <t>263 <iref item="validator" />264 <x:dfn>validator</x:dfn>265 <list>266 <t>A protocol element (e.g., an entity-tag or a267 <x:ref>Last-Modified</x:ref> time) that is used to find out whether a268 stored response is an equivalent copy of a representation. .</t>269 </list>270 </t>271 <t>272 <iref item="strong validator" />273 <iref item="validator" subitem="strong" />274 <x:dfn>strong validator</x:dfn>275 <list>276 <t>A validator that is defined by the origin server such that its277 current value will change if the representation data changes.278 See &weak-and-strong;</t>279 </list>280 </t>281 </section>282 283 176 <section title="Conformance and Error Handling" anchor="conformance"> 284 177 <t> … … 349 242 caching and defines something suitable for use as a cache key. 350 243 </t> 244 <iref item="cache key" /> 351 245 <t> 352 246 The primary <x:dfn>cache key</x:dfn> consists of the request method and … … 559 453 560 454 <section anchor="expiration.model" title="Freshness"> 455 <iref item="fresh" /> 456 <iref item="stale" /> 457 <t> 458 A <x:dfn>fresh</x:dfn> response is one whose age has not yet exceeded its 459 freshness lifetime. Conversely, a <x:dfn>stale</x:dfn> 460 response is one where it has. 461 </t> 462 <iref item="freshness lifetime" /> 463 <iref item="explicit expiration time" /> 464 <iref item="heuristic expiration time" /> 465 <t> 466 A response's <x:dfn>freshness lifetime</x:dfn> is the length of time 467 between its generation by the origin server and its expiration time. An 468 <x:dfn>explicit expiration time</x:dfn> is the time at which the origin 469 server intends that a stored response can no longer be used by a cache 470 without further validation, whereas a <x:dfn>heuristic expiration 471 time</x:dfn> is assigned by a cache when no explicit expiriation time is 472 available. 473 </t> 474 <iref item="age" /> 475 <t> 476 A response's <x:dfn>age</x:dfn> is the time that has passed since it was 477 generated by, or successfully validated with, the origin server. 478 </t> 561 479 <t> 562 480 When a response is "fresh" in the cache, it can be used to satisfy … … 569 487 <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or 570 488 the max-age response cache directive (<xref 571 target="cache-response-directive.max-age" />). Generally, origin servers will572 assign future explicit expiration times to responses in the belief that the573 representation is not likely to change in a semantically significant way574 before the expiration time is reached.489 target="cache-response-directive.max-age" />). Generally, origin servers 490 will assign future explicit expiration times to responses in the belief 491 that the representation is not likely to change in a semantically 492 significant way before the expiration time is reached. 575 493 </t> 576 494 <t> … … 798 716 field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref> 799 717 header field), in which case the corrected_age_value &MAY; be used as the 800 corrected_initial_age.</t> 718 corrected_initial_age. 719 </t> 801 720 <t> 802 721 The current_age of a stored response can then be calculated by adding the … … 835 754 cache is disconnected. 836 755 </t> 837 <t> 838 note that if a cache receives a first-hand response (either an entire 839 response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would 840 normally forward to the requesting client, and the received response is no 841 longer fresh, the cache can forward it to the requesting client without 842 adding a new <x:ref>Warning</x:ref> (but without removing any existing 843 Warning header fields). A cache shouldn't attempt to validate a response 844 simply because that response became stale in transit. 756 <iref item="first-hand" /> 757 <t> 758 Note that if a cache receives a <x:dfn>first-hand</x:dfn> response (one 759 where the freshness model is not in use; i.e., its age is 0, whether it is 760 an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that 761 it would normally forward to the requesting client, and the received 762 response is no longer fresh, the cache can forward it to the requesting 763 client without adding a new <x:ref>Warning</x:ref> (but without removing 764 any existing Warning header fields). A cache shouldn't attempt to validate 765 a response simply because that response became stale in transit. 845 766 </t> 846 767 </section> … … 857 778 "validating" or "revalidating" the stored response. 858 779 </t> 859 <t> 860 When sending such a conditional request, a cache adds an 861 <x:ref>If-Modified-Since</x:ref> header field whose value is that of the 862 <x:ref>Last-Modified</x:ref> header field from the selected 863 (see <xref target="caching.negotiated.responses"/>) stored response, if 864 available. 865 </t> 866 <t> 867 Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field 780 <iref item="validator" /> 781 <t> 782 When sending such a conditional request, a cache adds a 783 <x:dfn>validator</x:dfn> (or more than one), that is used to find 784 out whether a stored response is an equivalent copy of a current 785 representation of the resource. 786 </t> 787 <t> 788 One such validator is the <x:ref>If-Modified-Since</x:ref> header field, 789 whose value is that of the <x:ref>Last-Modified</x:ref> header field from 790 the selected (see <xref target="caching.negotiated.responses"/>) stored 791 response, if available. 792 </t> 793 <t> 794 Another is the <x:ref>If-None-Match</x:ref> header field, 868 795 whose value is that of the <x:ref>ETag</x:ref> header field(s) from 869 796 relevant responses stored for the primary cache key, if present. However, … … 909 836 with the new information provided in the <x:ref>304</x:ref> response. 910 837 </t> 838 <iref item="strong validator" /> 911 839 <t> 912 840 The stored response to update is identified by using the first match (if … … 914 842 <list style="symbols"> 915 843 <t> 916 If the new response contains a strong validator, then that strong 917 validator identifies the selected representation for update. All of the 918 stored responses with the same strong validator are selected. If none of 919 the stored responses contain the same strong validator, then the new 920 response &MUST-NOT; be used to update any stored responses. 844 If the new response contains a <x:dfn>strong validator</x:dfn> (see 845 &weak-and-strong;), then that strong validator identifies the selected 846 representation for update. All of the stored responses with the same 847 strong validator are selected. If none of the stored responses contain 848 the same strong validator, then the new response &MUST-NOT; be used to 849 update any stored responses. 921 850 </t> 922 851 <t>
Note: See TracChangeset
for help on using the changeset viewer.