Changeset 1112
- Timestamp:
- 10/02/11 05:52:29 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1110 r1112 632 632 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.terminology" href="#intro.terminology">Terminology</a></h2> 633 633 <p id="rfc.section.1.2.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, HTTP caching.</p> 634 <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span> <dfn>cacheable</dfn> 635 </p> 636 <ul class="empty"> 637 <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 638 Even when a response is cacheable, there might be additional constraints on whether a cache can use the cached copy to satisfy 639 a particular request. 640 </li> 641 </ul> 642 <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.e.1"></span> <dfn>explicit expiration time</dfn> 643 </p> 644 <ul class="empty"> 645 <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li> 646 </ul> 647 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 648 </p> 649 <ul class="empty"> 650 <li>An expiration time assigned by a cache when no explicit expiration time is available.</li> 651 </ul> 652 <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 653 </p> 654 <ul class="empty"> 655 <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li> 656 </ul> 657 <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 658 </p> 659 <ul class="empty"> 660 <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li> 661 </ul> 662 <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 663 </p> 664 <ul class="empty"> 665 <li>The length of time between the generation of a response and its expiration time.</li> 666 </ul> 667 <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 668 </p> 669 <ul class="empty"> 670 <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li> 671 </ul> 672 <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.s.1"></span> <dfn>stale</dfn> 673 </p> 674 <ul class="empty"> 675 <li>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</li> 676 </ul> 677 <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> 678 </p> 679 <ul class="empty"> 680 <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response has an 681 equivalent copy of a representation. 634 <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span> <dfn>cache</dfn> 635 </p> 636 <ul class="empty"> 637 <li>A conformant implementation of a HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define 638 conformance for HTTP/1.0 caches. 682 639 </li> 683 640 </ul> 684 641 <div id="shared.and.non-shared.caches"> 685 <p id="rfc.section.1.2.p. 11"> <span id="rfc.iref.v.2"></span> <dfn>shared cache</dfn>642 <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.s.1"></span> <dfn>shared cache</dfn> 686 643 </p> 687 644 <ul class="empty"> 688 <li>A cache that is accessible to more than one user . A non-shared cache is dedicated to a single user.</li>645 <li>A cache that is accessible to more than one user; usually (but not always) deployed as part of an intermediary.</li> 689 646 </ul> 690 647 </div> 648 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.p.1"></span> <dfn>private cache</dfn> 649 </p> 650 <ul class="empty"> 651 <li>A cache that is dedicated to a single user.</li> 652 </ul> 653 <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.c.3"></span> <dfn>cacheable</dfn> 654 </p> 655 <ul class="empty"> 656 <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 657 Even when a response is cacheable, there might be additional constraints on whether a cache can use the stored copy to satisfy 658 a particular request. 659 </li> 660 </ul> 661 <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.e.1"></span> <dfn>explicit expiration time</dfn> 662 </p> 663 <ul class="empty"> 664 <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li> 665 </ul> 666 <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 667 </p> 668 <ul class="empty"> 669 <li>An expiration time assigned by a cache when no explicit expiration time is available.</li> 670 </ul> 671 <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 672 </p> 673 <ul class="empty"> 674 <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li> 675 </ul> 676 <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 677 </p> 678 <ul class="empty"> 679 <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li> 680 </ul> 681 <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 682 </p> 683 <ul class="empty"> 684 <li>The length of time between the generation of a response and its expiration time.</li> 685 </ul> 686 <p id="rfc.section.1.2.p.11"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 687 </p> 688 <ul class="empty"> 689 <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li> 690 </ul> 691 <p id="rfc.section.1.2.p.12"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> 692 </p> 693 <ul class="empty"> 694 <li>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</li> 695 </ul> 696 <p id="rfc.section.1.2.p.13"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> 697 </p> 698 <ul class="empty"> 699 <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an 700 equivalent copy of a representation. 701 </li> 702 </ul> 691 703 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> 692 704 <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" … … 780 792 </li> 781 793 </ul> 782 <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, caches<em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>.783 </p> 784 <p id="rfc.section.2.2.p.3"> Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., a cache must not reply to such a request before having forwarded785 the request andhaving received a corresponding response.794 <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 795 </p> 796 <p id="rfc.section.2.2.p.3">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 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache must not generate a reply to such a request before having forwarded the request and 797 having received a corresponding response. 786 798 </p> 787 799 <p id="rfc.section.2.2.p.4">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>. 788 800 </p> 789 <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. They 790 can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to 791 use. 792 </p> 793 <p id="rfc.section.2.2.p.6">An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> used stored responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard. 801 <p id="rfc.section.2.2.p.5">A cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. It can 802 also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use. 803 </p> 804 <p id="rfc.section.2.2.p.6">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> used stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard. 794 805 </p> 795 806 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> … … 805 816 requests. 806 817 </p> 807 <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other heade field values808 (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1specification does not provide specific818 <p id="rfc.section.2.3.p.4">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 819 values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific 809 820 algorithms, but does impose worst-case constraints on their results. 810 821 </p> … … 836 847 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4> 837 848 <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 838 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for responsestatus codes that do not explicitly allow it.839 </p> 840 <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, thecache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning849 to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it. 850 </p> 851 <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning 841 852 is not already present. 842 853 </p> 843 <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. 854 <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this 855 fraction might be 10%. 844 856 </p> 845 857 <div class="note" id="rfc.section.2.3.1.1.p.4"> … … 873 885 </p> 874 886 <ul class="empty"> 875 <li>The term "now" means "the current value of the clock at the host performing the calculation". Hosts that use HTTP, but especially 876 hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize their clocks to a globally accurate time standard. 887 <li>The term "now" means "the current value of the clock at the host performing the calculation". A cache <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to a globally accurate time standard. 877 888 </li> 878 889 </ul> … … 892 903 clock. If the result is negative, the result is replaced by zero. 893 904 </li> 894 <li>the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1 ; note this value <em class="bcp14">MUST</em> be interpretedrelative to the time the request was initiated, not the time that the response was received.905 <li>the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1. A cache <em class="bcp14">MUST</em> interpret this value relative to the time the request was initiated, not the time that the response was received. 895 906 </li> 896 907 </ol> … … 910 921 is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>. 911 922 </p> 912 <p id="rfc.section.2.3.3.p.2"> Caches<em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache923 <p id="rfc.section.2.3.3.p.2">A cache <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 913 924 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 914 925 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). 915 926 </p> 916 <p id="rfc.section.2.3.3.p.3"> Caches <em class="bcp14">SHOULD NOT</em> return stale responses unless they are disconnected (i.e., it cannot contact the origin server or otherwise find a forward917 path)or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>).918 </p> 919 <p id="rfc.section.2.3.3.p.4"> Stale responses <em class="bcp14">SHOULD</em> have a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent onstale responses if the cache is disconnected.927 <p id="rfc.section.2.3.3.p.3">A cache <em class="bcp14">SHOULD NOT</em> return stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) 928 or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>). 929 </p> 930 <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 3.6</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. 920 931 </p> 921 932 <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally … … 928 939 update it. This process is known as "validating" or "revalidating" the stored response. 929 940 </p> 930 <p id="rfc.section.2.4.p.2">When sending such a conditional request, thecache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>) stored response, if available.931 </p> 932 <p id="rfc.section.2.4.p.3">Additionally, thecache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested933 URI, if present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored934 response.941 <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>) stored response, if available. 942 </p> 943 <p id="rfc.section.2.4.p.3">Additionally, a cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested 944 URI, if present. However, if any of the stored responses contains only partial content, the cache <em class="bcp14">SHOULD NOT</em> include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by 945 that stored response. 935 946 </p> 936 947 <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.responses" title="Combining Responses">Section 2.8</a>. 937 948 </p> 938 949 <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional 939 request is suitable. Instead, the full response <em class="bcp14">SHOULD</em> be usedto satisfy the request and <em class="bcp14">MAY</em> replace the stored response.950 request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response. 940 951 </p> 941 952 <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 942 953 </p> 943 954 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 944 <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 945 </p> 946 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present): 955 <p id="rfc.section.2.5.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 956 </p> 957 <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when the following request methods 958 are received: 947 959 </p> 948 960 <ul> … … 951 963 <li>POST</li> 952 964 </ul> 953 <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header field <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 954 </p> 955 <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 965 <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part 966 in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 967 </p> 968 <p id="rfc.section.2.5.p.4">A cache that passes through requests with methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 956 969 </p> 957 970 <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will … … 962 975 </p> 963 976 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2> 964 <p id="rfc.section.2.6.p.1"> Shared caches<em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.977 <p id="rfc.section.2.6.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response. 965 978 </p> 966 979 <p id="rfc.section.2.6.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage. … … 1001 1014 <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-select-for-combine">[<a href="#TODO-select-for-combine" class="smpl">TODO-select-for-combine</a>: Shouldn't this be the selected response?]</span> 1002 1015 </p> 1003 <p id="rfc.section.2.8.p.3"> If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.1016 <p id="rfc.section.2.8.p.3">When the new response's status code is 206 (partial content), a cache <em class="bcp14">MUST NOT</em> combine it with the old response if either response does not have a validator, and <em class="bcp14">MUST NOT</em> combine it with the old response when those validators do not match with the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1004 1017 </p> 1005 1018 <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p> 1006 1019 <ul> 1007 <li>any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted. 1008 </li> 1009 <li>any stored Warning header fields with warn-code 2xx <em class="bcp14">MUST</em> be retained. 1010 </li> 1011 <li>any other header fields provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding header fields from the stored response. 1012 </li> 1013 </ul> 1014 <p id="rfc.section.2.8.p.5">The updated response header fields <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of 1015 a 206 response, the combined representation <em class="bcp14">MAY</em> be stored. 1020 <li>a cache <em class="bcp14">MUST</em> delete any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>). 1021 </li> 1022 <li>a cache <em class="bcp14">MUST</em> retain any stored Warning header fields with warn-code 2xx. 1023 </li> 1024 <li>a cache <em class="bcp14">MUST</em> use other header fields provided in the new response to replace all instances of the corresponding header fields from the 1025 stored response. 1026 </li> 1027 </ul> 1028 <p id="rfc.section.2.8.p.5">A cache <em class="bcp14">MUST</em> use the updated response header fields to replace those of the stored response (unless the stored response is removed). In 1029 the case of a 206 response, a cache <em class="bcp14">MAY</em> store the combined representation. 1016 1030 </p> 1017 1031 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1030 1044 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 1031 1045 </pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, 1032 it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Caches<em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.1046 it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Recipients parsing the Age header field-value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range. 1033 1047 </p> 1034 1048 <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not 1035 1049 true, since HTTP/1.0 caches might not implement the Age header field. 1036 1050 </p> 1037 <div id="rfc.iref.c. 3"></div>1051 <div id="rfc.iref.c.4"></div> 1038 1052 <div id="rfc.iref.h.3"></div> 1039 1053 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> … … 1042 1056 be given in the response. 1043 1057 </p> 1044 <p id="rfc.section.3.2.p.2"> HTTP/1.1 caches<em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.1058 <p id="rfc.section.3.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled. 1045 1059 </p> 1046 1060 <div class="note" id="rfc.section.3.2.p.3"> … … 1048 1062 </p> 1049 1063 </div> 1050 <p id="rfc.section.3.2.p.4">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 1051 might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific 1052 cache. 1064 <p id="rfc.section.3.2.p.4">An intermediary (i.e., a proxy or gateway, whether or not it implements a cache) <em class="bcp14">MUST</em> pass cache directives through, regardless of their significance to that application, since the directives might be applicable 1065 to all recipients along the request/response chain. It is not possible to target a directive to a specific cache. 1053 1066 </p> 1054 1067 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.cache-control" class="smpl">Cache-Control</a> = "Cache-Control" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.cache-control" class="smpl">Cache-Control-v</a> … … 1069 1082 / "only-if-cached" 1070 1083 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1071 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn> <span id="rfc.iref.c.4"></span> <span id="rfc.iref.n.1"></span> 1072 </p> 1073 <ul class="empty"> 1074 <li>The no-cache request directive indicates that a stored response <em class="bcp14">MUST NOT</em> be used to satisfy the request without successful validation on the origin server. 1075 </li> 1076 </ul> 1077 <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.n.2"></span> 1078 </p> 1079 <ul class="empty"> 1080 <li>The no-store request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both non-shared and shared caches. 1081 "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 1084 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn> <span id="rfc.iref.c.5"></span> <span id="rfc.iref.n.1"></span> 1085 </p> 1086 <ul class="empty"> 1087 <li>The no-cache request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server. 1088 </li> 1089 </ul> 1090 <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn> <span id="rfc.iref.c.6"></span> <span id="rfc.iref.n.2"></span> 1091 </p> 1092 <ul class="empty"> 1093 <li>The no-store request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 1082 1094 </li> 1083 1095 <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches … … 1088 1100 </li> 1089 1101 </ul> 1090 <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn> <span id="rfc.iref.c. 6"></span> <span id="rfc.iref.m.1"></span>1102 <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.m.1"></span> 1091 1103 </p> 1092 1104 <ul class="empty"> … … 1095 1107 </li> 1096 1108 </ul> 1097 <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn> <span id="rfc.iref.c. 7"></span> <span id="rfc.iref.m.2"></span>1109 <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.m.2"></span> 1098 1110 </p> 1099 1111 <ul class="empty"> … … 1104 1116 </li> 1105 1117 </ul> 1106 <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn> <span id="rfc.iref.c. 8"></span> <span id="rfc.iref.m.3"></span>1118 <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.3"></span> 1107 1119 </p> 1108 1120 <ul class="empty"> … … 1112 1124 </li> 1113 1125 </ul> 1114 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c. 9"></span> <span id="rfc.iref.n.3"></span>1115 </p> 1116 <ul class="empty"> 1117 <li>The no-transform request directive indicates that an intermedia te cache or proxy<em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation.1118 </li> 1119 </ul> 1120 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.1 0"></span> <span id="rfc.iref.o.1"></span>1126 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.n.3"></span> 1127 </p> 1128 <ul class="empty"> 1129 <li>The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation. 1130 </li> 1131 </ul> 1132 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.o.1"></span> 1121 1133 </p> 1122 1134 <ul class="empty"> … … 1124 1136 directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 1125 1137 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, 1126 such a request <em class="bcp14">MAY</em> be forwardedwithin that group of caches.1138 a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches. 1127 1139 </li> 1128 1140 </ul> … … 1139 1151 / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 1140 1152 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1141 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.1 1"></span> <span id="rfc.iref.p.1"></span>1142 </p> 1143 <ul class="empty"> 1144 <li>The public response directive indicates that the response <em class="bcp14">MAY</em> be cached, even if it would normally be non-cacheable or cacheable only within a non-sharedcache. (See also Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.)1145 </li> 1146 </ul> 1147 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.1 2"></span> <span id="rfc.iref.p.2"></span>1148 </p> 1149 <ul class="empty"> 1150 <li>The private response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private (non-shared)cache <em class="bcp14">MAY</em> store the response.1153 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.p.2"></span> 1154 </p> 1155 <ul class="empty"> 1156 <li>The public response directive indicates that a cache <em class="bcp14">MAY</em> store the response, even if it would normally be non-cacheable or cacheable only within a private cache. (See also Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.) 1157 </li> 1158 </ul> 1159 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.p.3"></span> 1160 </p> 1161 <ul class="empty"> 1162 <li>The private response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response. 1151 1163 </li> 1152 1164 <li>If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated 1153 with the listed response header fields. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.1165 with the listed response header fields. That is, a shared cache <em class="bcp14">MUST NOT</em> store the specified field-names(s), whereas it <em class="bcp14">MAY</em> store the remainder of the response message. 1154 1166 </li> 1155 1167 <li> <b>Note:</b> This usage of the word private only controls where the response can be stored; it cannot ensure the privacy of the message … … 1158 1170 </li> 1159 1171 </ul> 1160 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.1 3"></span> <span id="rfc.iref.n.4"></span>1172 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.n.4"></span> 1161 1173 </p> 1162 1174 <ul class="empty"> … … 1166 1178 </li> 1167 1179 <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated 1168 with the listed response header fields. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin 1169 server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 1180 with the listed response header fields. That is, a cache <em class="bcp14">MUST NOT</em> send the specified field-name(s) in the response to a subsequent request without successful validation on the origin server. 1181 This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of 1182 the rest of the response. 1170 1183 </li> 1171 1184 <li> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often … … 1174 1187 </li> 1175 1188 </ul> 1176 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.1 4"></span> <span id="rfc.iref.n.5"></span>1177 </p> 1178 <ul class="empty"> 1179 <li>The no-store response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both non-sharedand shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.1189 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.n.5"></span> 1190 </p> 1191 <ul class="empty"> 1192 <li>The no-store response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 1180 1193 </li> 1181 1194 <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches … … 1183 1196 </li> 1184 1197 </ul> 1185 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.1 5"></span> <span id="rfc.iref.m.4"></span>1186 </p> 1187 <ul class="empty"> 1188 <li>The must-revalidate response directive indicates that once it has become stale, the response <em class="bcp14">MUST NOT</em> be usedto satisfy subsequent requests without successful validation on the origin server.1198 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.m.4"></span> 1199 </p> 1200 <ul class="empty"> 1201 <li>The must-revalidate response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server. 1189 1202 </li> 1190 1203 <li>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances 1191 a n HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if thecache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.1192 </li> 1193 <li> Servers<em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect1204 a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response. 1205 </li> 1206 <li>A server <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect 1194 1207 operation, such as a silently unexecuted financial transaction. 1195 1208 </li> 1196 1209 </ul> 1197 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.1 6"></span> <span id="rfc.iref.p.3"></span>1210 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.p.4"></span> 1198 1211 </p> 1199 1212 <ul class="empty"> 1200 1213 <li>The proxy-revalidate response directive has the same meaning as the must-revalidate response directive, except that it does 1201 not apply to non-sharedcaches.1202 </li> 1203 </ul> 1204 <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn> <span id="rfc.iref.c.1 7"></span> <span id="rfc.iref.m.5"></span>1214 not apply to private caches. 1215 </li> 1216 </ul> 1217 <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.m.5"></span> 1205 1218 </p> 1206 1219 <ul class="empty"> … … 1209 1222 </li> 1210 1223 </ul> 1211 <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn> <span id="rfc.iref.c.1 8"></span> <span id="rfc.iref.s.2"></span>1224 <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.s.3"></span> 1212 1225 </p> 1213 1226 <ul class="empty"> … … 1217 1230 </li> 1218 1231 </ul> 1219 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c. 19"></span> <span id="rfc.iref.n.6"></span>1220 </p> 1221 <ul class="empty"> 1222 <li>The no-transform response directive indicates that an intermedia te cache or proxy<em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation.1232 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c.20"></span> <span id="rfc.iref.n.6"></span> 1233 </p> 1234 <ul class="empty"> 1235 <li>The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation. 1223 1236 </li> 1224 1237 </ul> … … 1236 1249 </p> 1237 1250 <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive. 1238 We define this new directive to mean that, in addition to any non-shared cache, any cache that is shared only by members of1239 the community named within its value may cache the response. An origin server wishing to allow the UCI community to use an1240 otherwiseprivate response in their shared cache(s) could do so by including1251 We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the 1252 community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise 1253 private response in their shared cache(s) could do so by including 1241 1254 </p> 1242 1255 <div id="rfc.figure.u.12"></div><pre class="text"> Cache-Control: private, community="UCI" … … 1244 1257 it will also see and understand the private directive and thus default to the safe behavior. 1245 1258 </p> 1246 <p id="rfc.section.3.2.3.p.6"> Unrecognized cache directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard1247 directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the1248 cache does not understand the extension(s).1259 <p id="rfc.section.3.2.3.p.6">A cache <em class="bcp14">MUST</em> be ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache 1260 will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain 1261 minimally correct even if the cache does not understand the extension(s). 1249 1262 </p> 1250 1263 <p id="rfc.section.3.2.3.p.7">The HTTP Cache Directive Registry defines the name space for the cache directives.</p> 1251 <p id="rfc.section.3.2.3.p.8"> Registrations<em class="bcp14">MUST</em> include the following fields:1264 <p id="rfc.section.3.2.3.p.8">A registration <em class="bcp14">MUST</em> include the following fields: 1252 1265 </p> 1253 1266 <ul> … … 1267 1280 that time. 1268 1281 </p> 1269 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent inrfc1123-date format.1282 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format. 1270 1283 </p> 1271 1284 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a> … … 1277 1290 </p> 1278 1291 </div> 1279 <p id="rfc.section.3.3.p.7"> HTTP/1.1 servers<em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.1280 </p> 1281 <p id="rfc.section.3.3.p.8"> HTTP/1.1 clients and caches<em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").1282 </p> 1283 <div id="rfc.iref.p. 4"></div>1292 <p id="rfc.section.3.3.p.7">A server <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future. 1293 </p> 1294 <p id="rfc.section.3.3.p.8">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 1295 </p> 1296 <div id="rfc.iref.p.5"></div> 1284 1297 <div id="rfc.iref.h.5"></div> 1285 1298 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> … … 1292 1305 <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a> 1293 1306 <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ] 1294 </pre><p id="rfc.section.3.4.p.3">When the no-cache directive is present in a request message, a n application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive1295 has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches<em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".1307 </pre><p id="rfc.section.3.4.p.3">When the no-cache directive is present in a request message, a cache <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a stored copy of what is being requested. This pragma directive 1308 has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. A client <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. A cache <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". 1296 1309 </p> 1297 1310 <div class="note" id="rfc.section.3.4.p.4"> … … 1301 1314 </div> 1302 1315 <p id="rfc.section.3.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p> 1303 <div id="rfc.iref.v. 3"></div>1316 <div id="rfc.iref.v.2"></div> 1304 1317 <div id="rfc.iref.h.6"></div> 1305 1318 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> … … 1314 1327 <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a> 1315 1328 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p> 1316 <p id="rfc.section.3.5.p.6"> Servers<em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache1329 <p id="rfc.section.3.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache 1317 1330 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that 1318 1331 resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide … … 1321 1334 <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network 1322 1335 address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether 1323 this response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.1336 this response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value. 1324 1337 </p> 1325 1338 <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names … … 1362 1375 </p> 1363 1376 <ul> 1364 <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by cachesafter validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation.1377 <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation. 1365 1378 </li> 1366 1379 <li>2xx Warnings describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression 1367 of the representation) and <em class="bcp14">MUST NOT</em> be deleted by cachesafter validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.1380 of the representation) and <em class="bcp14">MUST NOT</em> be deleted by a cache after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be. 1368 1381 </li> 1369 1382 </ul> … … 1371 1384 then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message. 1372 1385 </p> 1373 <p id="rfc.section.3.6.p.10">If a n implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from1374 the Datevalue in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning1386 <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date 1387 value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning 1375 1388 header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well. 1376 1389 </p> … … 1380 1393 <p id="rfc.section.3.6.p.12"> 110 Response is stale </p> 1381 1394 <ul class="empty"> 1382 <li> <em class="bcp14">SHOULD</em> be includedwhenever the returned response is stale.1395 <li>A cache <em class="bcp14">SHOULD</em> include this whenever the returned response is stale. 1383 1396 </li> 1384 1397 </ul> 1385 1398 <p id="rfc.section.3.6.p.13"> 111 Revalidation failed </p> 1386 1399 <ul class="empty"> 1387 <li> <em class="bcp14">SHOULD</em> be included if a cache returns a stale response because an attempt to validate the response failed, due to an inability to1388 reachthe server.1400 <li>A cache <em class="bcp14">SHOULD</em> include this when returning a stale response because an attempt to validate the response failed, due to an inability to reach 1401 the server. 1389 1402 </li> 1390 1403 </ul> 1391 1404 <p id="rfc.section.3.6.p.14"> 112 Disconnected operation </p> 1392 1405 <ul class="empty"> 1393 <li> <em class="bcp14">SHOULD</em> be included if the cacheis intentionally disconnected from the rest of the network for a period of time.1406 <li>A cache <em class="bcp14">SHOULD</em> b include this if it is intentionally disconnected from the rest of the network for a period of time. 1394 1407 </li> 1395 1408 </ul> 1396 1409 <p id="rfc.section.3.6.p.15"> 113 Heuristic expiration </p> 1397 1410 <ul class="empty"> 1398 <li> <em class="bcp14">SHOULD</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater1399 than 24hours.1411 <li>A cache <em class="bcp14">SHOULD</em> include this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 1412 hours. 1400 1413 </li> 1401 1414 </ul> … … 1407 1420 <p id="rfc.section.3.6.p.17"> 214 Transformation applied </p> 1408 1421 <ul class="empty"> 1409 <li><em class="bcp14">MUST</em> be added by a n intermediate proxy if it applies any transformation to the representation, such as changing the content-coding,1410 media-type,or modifying the representation data, unless this Warning code already appears in the response.1422 <li><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, 1423 or modifying the representation data, unless this Warning code already appears in the response. 1411 1424 </li> 1412 1425 </ul> … … 1933 1946 </li> 1934 1947 <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> 1935 <li>cache <a href="#rfc.iref.c.1">1.1</a> </li>1948 <li>cache <a href="#rfc.iref.c.1">1.1</a>, <a href="#rfc.iref.c.2">1.2</a></li> 1936 1949 <li>Cache Directives 1937 1950 <ul> 1938 <li>max-age <a href="#rfc.iref.c. 6"><b>3.2.1</b></a>, <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li>1939 <li>max-stale <a href="#rfc.iref.c. 7"><b>3.2.1</b></a></li>1940 <li>min-fresh <a href="#rfc.iref.c. 8"><b>3.2.1</b></a></li>1941 <li>must-revalidate <a href="#rfc.iref.c.1 5"><b>3.2.2</b></a></li>1942 <li>no-cache <a href="#rfc.iref.c. 4"><b>3.2.1</b></a>, <a href="#rfc.iref.c.13"><b>3.2.2</b></a></li>1943 <li>no-store <a href="#rfc.iref.c. 5"><b>3.2.1</b></a>, <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li>1944 <li>no-transform <a href="#rfc.iref.c. 9"><b>3.2.1</b></a>, <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li>1945 <li>only-if-cached <a href="#rfc.iref.c.1 0"><b>3.2.1</b></a></li>1946 <li>private <a href="#rfc.iref.c.1 2"><b>3.2.2</b></a></li>1947 <li>proxy-revalidate <a href="#rfc.iref.c.1 6"><b>3.2.2</b></a></li>1948 <li>public <a href="#rfc.iref.c.1 1"><b>3.2.2</b></a></li>1949 <li>s-maxage <a href="#rfc.iref.c.1 8"><b>3.2.2</b></a></li>1950 </ul> 1951 </li> 1952 <li>Cache-Control header <a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c. 3"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>1953 <li>cacheable <a href="#rfc.iref.c. 2">1.2</a></li>1951 <li>max-age <a href="#rfc.iref.c.7"><b>3.2.1</b></a>, <a href="#rfc.iref.c.18"><b>3.2.2</b></a></li> 1952 <li>max-stale <a href="#rfc.iref.c.8"><b>3.2.1</b></a></li> 1953 <li>min-fresh <a href="#rfc.iref.c.9"><b>3.2.1</b></a></li> 1954 <li>must-revalidate <a href="#rfc.iref.c.16"><b>3.2.2</b></a></li> 1955 <li>no-cache <a href="#rfc.iref.c.5"><b>3.2.1</b></a>, <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li> 1956 <li>no-store <a href="#rfc.iref.c.6"><b>3.2.1</b></a>, <a href="#rfc.iref.c.15"><b>3.2.2</b></a></li> 1957 <li>no-transform <a href="#rfc.iref.c.10"><b>3.2.1</b></a>, <a href="#rfc.iref.c.20"><b>3.2.2</b></a></li> 1958 <li>only-if-cached <a href="#rfc.iref.c.11"><b>3.2.1</b></a></li> 1959 <li>private <a href="#rfc.iref.c.13"><b>3.2.2</b></a></li> 1960 <li>proxy-revalidate <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li> 1961 <li>public <a href="#rfc.iref.c.12"><b>3.2.2</b></a></li> 1962 <li>s-maxage <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li> 1963 </ul> 1964 </li> 1965 <li>Cache-Control header <a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.4"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li> 1966 <li>cacheable <a href="#rfc.iref.c.3">1.2</a></li> 1954 1967 </ul> 1955 1968 </li> … … 2088 2101 </ul> 2089 2102 </li> 2090 <li>Pragma header <a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.p. 4"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>2103 <li>Pragma header <a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.p.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li> 2091 2104 <li>private 2092 2105 <ul> 2093 <li>Cache Directive <a href="#rfc.iref.p.2"><b>3.2.2</b></a></li> 2094 </ul> 2095 </li> 2106 <li>Cache Directive <a href="#rfc.iref.p.3"><b>3.2.2</b></a></li> 2107 </ul> 2108 </li> 2109 <li>private cache <a href="#rfc.iref.p.1">1.2</a></li> 2096 2110 <li>proxy-revalidate 2097 2111 <ul> 2098 <li>Cache Directive <a href="#rfc.iref.p. 3"><b>3.2.2</b></a></li>2112 <li>Cache Directive <a href="#rfc.iref.p.4"><b>3.2.2</b></a></li> 2099 2113 </ul> 2100 2114 </li> 2101 2115 <li>public 2102 2116 <ul> 2103 <li>Cache Directive <a href="#rfc.iref.p. 1"><b>3.2.2</b></a></li>2117 <li>Cache Directive <a href="#rfc.iref.p.2"><b>3.2.2</b></a></li> 2104 2118 </ul> 2105 2119 </li> … … 2132 2146 <li>s-maxage 2133 2147 <ul> 2134 <li>Cache Directive <a href="#rfc.iref.s.2"><b>3.2.2</b></a></li> 2135 </ul> 2136 </li> 2137 <li>stale <a href="#rfc.iref.s.1">1.2</a></li> 2148 <li>Cache Directive <a href="#rfc.iref.s.3"><b>3.2.2</b></a></li> 2149 </ul> 2150 </li> 2151 <li>shared cache <a href="#rfc.iref.s.1">1.2</a></li> 2152 <li>stale <a href="#rfc.iref.s.2">1.2</a></li> 2138 2153 </ul> 2139 2154 </li> 2140 2155 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2141 <li>validator <a href="#rfc.iref.v.1">1.2</a> , <a href="#rfc.iref.v.2">1.2</a></li>2142 <li>Vary header <a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v. 3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>2156 <li>validator <a href="#rfc.iref.v.1">1.2</a></li> 2157 <li>Vary header <a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.2"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li> 2143 2158 </ul> 2144 2159 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r1110 r1112 264 264 </t> 265 265 <t> 266 <iref item="cache" /> 267 <x:dfn>cache</x:dfn> 268 <list> 269 <t>A conformant implementation of a HTTP cache. Note that this implies 270 an HTTP/1.1 cache; this specification does not define conformance 271 for HTTP/1.0 caches.</t> 272 </list> 273 </t> 274 <t anchor="shared.and.non-shared.caches"> 275 <iref item="shared cache" /> 276 <x:dfn>shared cache</x:dfn> 277 <list> 278 <t>A cache that is accessible to more than one user; usually (but 279 not always) deployed as part of an intermediary.</t> 280 </list> 281 </t> 282 <t> 283 <iref item="private cache" /> 284 <x:dfn>private cache</x:dfn> 285 <list> 286 <t>A cache that is dedicated to a single user.</t> 287 </list> 288 </t> 289 <t> 266 290 <iref item="cacheable" /> 267 291 <x:dfn>cacheable</x:dfn> … … 270 294 response message for use in answering subsequent requests. Even when a 271 295 response is cacheable, there might be additional constraints on whether 272 a cache can use the cached copy to satisfy a particular request.</t>296 a cache can use the stored copy to satisfy a particular request.</t> 273 297 </list> 274 298 </t> … … 334 358 <list> 335 359 <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that 336 is used to find out whether a stored response has an equivalent copy of360 is used to find out whether a stored response is an equivalent copy of 337 361 a representation.</t> 338 </list>339 </t>340 <t anchor="shared.and.non-shared.caches">341 <iref item="validator" />342 <x:dfn>shared cache</x:dfn>343 <list>344 <t>A cache that is accessible to more than one user. A non-shared cache345 is dedicated to a single user.</t>346 362 </list> 347 363 </t> … … 525 541 <t> 526 542 When a stored response is used to satisfy a request without validation, 527 caches&MUST; include a single Age header field (<xref target="header.age"543 a cache &MUST; include a single Age header field (<xref target="header.age" 528 544 />) in the response with a value equal to the stored response's 529 545 current_age; see <xref target="age.calculations" />. 530 546 </t> 531 547 <t> 532 Requests with methods that are unsafe (&safe-methods;) &MUST; be written533 through the cache to the origin server; i.e., a cache must not reply to534 such a request before having forwarded the request and having received a535 corresponding response.548 A cache &MUST; write through requests with methods that are unsafe 549 (&safe-methods;) to the origin server; i.e., a cache must not generate 550 a reply to such a request before having forwarded the request and having 551 received a corresponding response. 536 552 </t> 537 553 <t> … … 540 556 </t> 541 557 <t> 542 Caches&MUST; use the most recent response (as determined by the Date543 header field) when more than one suitable response is stored. Theycan also558 A cache &MUST; use the most recent response (as determined by the Date 559 header field) when more than one suitable response is stored. It can also 544 560 forward a request with "Cache-Control: max-age=0" or "Cache-Control: 545 561 no-cache" to disambiguate which response to use. 546 562 </t> 547 563 <t> 548 A n HTTP implementation without a clock&MUST-NOT; used stored responses549 without revalidating them on every use. A n HTTPcache, especially a shared564 A cache that does not have a clock available &MUST-NOT; used stored responses 565 without revalidating them on every use. A cache, especially a shared 550 566 cache, &SHOULD; use a mechanism, such as NTP <xref target="RFC1305"/>, to 551 567 synchronize its clock with a reliable external standard. … … 576 592 </t> 577 593 <t> 578 Since origin servers do not always provide explicit expiration times, HTTP579 caches &MAY; assign heuristic expiration times when explicit times arenot580 specified, employing algorithms that use other heade field values (such as the581 Last-Modified time) to estimate a plausible expiration time. Th e HTTP/1.1594 Since origin servers do not always provide explicit expiration times, 595 a cache &MAY; assign a heuristic expiration time when an explicit time is not 596 specified, employing algorithms that use other header field values (such as the 597 Last-Modified time) to estimate a plausible expiration time. This 582 598 specification does not provide specific algorithms, but does impose 583 599 worst-case constraints on their results. … … 642 658 status code whose definition allows heuristic freshness to be used 643 659 (including the following in &status-codes;: 200, 203, 206, 300, 301 and 644 410), a heuristic expiration time &MAY; be calculated. Heuristics645 &MUST-NOT; be used for response status codes that do not explicitly allow646 it.647 </t> 648 <t> 649 When a heuristic is used to calculate freshness lifetime, thecache660 410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 661 use heuristics to determine freshness for responses with status codes that do 662 not explicitly allow it. 663 </t> 664 <t> 665 When a heuristic is used to calculate freshness lifetime, a cache 650 666 &SHOULD; attach a Warning header field with a 113 warn-code to the response if 651 667 its current_age is more than 24 hours and such a warning is not already … … 654 670 <t> 655 671 Also, if the response has a Last-Modified header field (&header-last-modified;), 656 the heuristic expiration value &SHOULD; be no more than some fraction of657 the interval since that time. A typical setting of this fraction might be658 10%.672 a cache &SHOULD-NOT; use a heuristic expiration value that is more than some 673 fraction of the interval since that time. A typical setting of this fraction 674 might be 10%. 659 675 </t> 660 676 <x:note> … … 712 728 <t> 713 729 The term "now" means "the current value of the clock at the host 714 performing the calculation". Hosts that use HTTP, but especially 715 hosts running origin servers and caches, &SHOULD; use NTP (<xref 716 target="RFC1305"/>) or some similar protocol to synchronize their 730 performing the calculation". A cache &SHOULD; use NTP (<xref 731 target="RFC1305"/>) or some similar protocol to synchronize its 717 732 clocks to a globally accurate time standard. 718 733 </t> … … 744 759 the result is negative, the result is replaced by zero.</t> 745 760 <t>the "corrected_age_value", if all of the caches along the response 746 path implement HTTP/1.1 ; note this value &MUST; be interpretedrelative761 path implement HTTP/1.1. A cache &MUST; interpret this value relative 747 762 to the time the request was initiated, not the time that the response 748 763 was received.</t> … … 780 795 </t> 781 796 <t> 782 Caches&MUST-NOT; return a stale response if it is prohibited by an797 A cache &MUST-NOT; return a stale response if it is prohibited by an 783 798 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 784 799 directive, a "must-revalidate" cache-response-directive, or an applicable … … 787 802 </t> 788 803 <t> 789 Caches &SHOULD-NOT; return stale responses unless they aredisconnected804 A cache &SHOULD-NOT; return stale responses unless it is disconnected 790 805 (i.e., it cannot contact the origin server or otherwise find a forward 791 806 path) or otherwise explicitly allowed (e.g., the max-stale request … … 793 808 </t> 794 809 <t> 795 Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see 796 <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be 797 sent on stale responses if the cache is disconnected. 810 A cache &SHOULD; append a Warning header field with the 110 warn-code (see 811 <xref target="header.warning" />) to stale responses. Likewise, a cache 812 &SHOULD; add the 112 warn-code to stale responses if the cache is 813 disconnected. 798 814 </t> 799 815 <t> … … 820 836 </t> 821 837 <t> 822 When sending such a conditional request, thecache &SHOULD; add an838 When sending such a conditional request, a cache &SHOULD; add an 823 839 If-Modified-Since header field whose value is that of the Last-Modified header 824 840 field from the selected (see <xref target="caching.negotiated.responses"/>) … … 826 842 </t> 827 843 <t> 828 Additionally, thecache &SHOULD; add an If-None-Match header field whose value is844 Additionally, a cache &SHOULD; add an If-None-Match header field whose value is 829 845 that of the ETag header field(s) from all responses stored for the requested URI, 830 846 if present. However, if any of the stored responses contains only partial 831 content, its entity-tag &SHOULD-NOT; be includedin the If-None-Match847 content, the cache &SHOULD-NOT; include its entity-tag in the If-None-Match 832 848 header field unless the request is for a range that would be fully 833 849 satisfied by that stored response. … … 840 856 A full response (i.e., one with a response body) indicates that none of the 841 857 stored responses nominated in the conditional request is suitable. Instead, 842 the full response &SHOULD; be used to satisfy the request and &MAY; replace843 the stored response.858 a cache &SHOULD; use the full response to satisfy the request and &MAY; 859 replace the stored response. 844 860 </t> 845 861 <t> … … 854 870 title="Request Methods that Invalidate"> 855 871 <t> 856 Because unsafe methods (&safe-methods;) have the potential for changing872 Because unsafe request methods (&safe-methods;) have the potential for changing 857 873 state on the origin server, intervening caches can use them to keep their 858 874 contents up-to-date. 859 875 </t> 860 876 <t> 861 The following HTTP methods &MUST; cause a cache to invalidate the effective 862 Request URI (&effective-request-uri;) as well as the URI(s) in the Location 863 and Content-Location header fields (if present): 877 A cache &MUST; invalidate the effective Request URI 878 (&effective-request-uri;) as well as the URI(s) in the Location 879 and Content-Location header fields (if present) when the following 880 request methods are received: 864 881 <list style="symbols"> 865 882 <t>PUT</t> … … 869 886 </t> 870 887 <t> 871 An invalidation based on a URI from a Location or Content-Location header field872 &MUST-NOT; be performed if the host part of that URI differs from the host873 part in the effective request URI (&effective-request-uri;). This helps874 prevent denial of service attacks.875 </t> 876 <t> 877 A cache that passes through requests formethods it does not understand888 However, a cache &MUST-NOT; invalidate a URI from a 889 Location or Content-Location header field if the host part of that URI 890 differs from the host part in the effective request URI 891 (&effective-request-uri;). This helps prevent denial of service attacks. 892 </t> 893 <t> 894 A cache that passes through requests with methods it does not understand 878 895 &SHOULD; invalidate the effective request URI (&effective-request-uri;). 879 896 </t> … … 895 912 896 913 <t> 897 Shared caches&MUST-NOT; use a cached response to a request with an914 A shared cache &MUST-NOT; use a cached response to a request with an 898 915 Authorization header field (&header-authorization;) to satisfy any subsequent 899 916 request unless a cache directive that allows such responses to be stored is … … 983 1000 </t> 984 1001 <t> 985 If the new response's status code is 206 (partial content), both the stored 986 and new responses &MUST; have validators, and those validators &MUST; match 987 using the strong comparison function (see &weak-and-strong;). Otherwise, 988 the responses &MUST-NOT; be combined. 1002 When the new response's status code is 206 (partial content), a cache 1003 &MUST-NOT; combine it with the old response if either response does not 1004 have a validator, and &MUST-NOT; combine it with the old response when 1005 those validators do not match with the strong comparison function 1006 (see &weak-and-strong;). 989 1007 </t> 990 1008 <t> … … 992 1010 except that 993 1011 <list style="symbols"> 994 <t>a ny stored Warning header fields with warn-code 1xx (see <xref995 target="header.warning" />) &MUST; be deleted.</t>996 <t>a ny stored Warning header fields with warn-code 2xx &MUST; be retained.</t>997 <t>a ny other header fields provided in the new response &MUST;replace all1012 <t>a cache &MUST; delete any stored Warning header fields with warn-code 1xx (see <xref 1013 target="header.warning" />).</t> 1014 <t>a cache &MUST; retain any stored Warning header fields with warn-code 2xx.</t> 1015 <t>a cache &MUST; use other header fields provided in the new response to replace all 998 1016 instances of the corresponding header fields from the stored response.</t> 999 1017 </list> 1000 1018 </t> 1001 1019 <t> 1002 The updated response header fields &MUST; be usedto replace those of the stored1003 response in cache (unless the stored response is removed from cache). In1004 the case of a 206 response, the combined representation &MAY; be stored.1020 A cache &MUST; use the updated response header fields to replace those of the stored 1021 response (unless the stored response is removed). In 1022 the case of a 206 response, a cache &MAY; store the combined representation. 1005 1023 </t> 1006 1024 </section> … … 1040 1058 If a cache receives a value larger than the largest positive integer it can 1041 1059 represent, or if any of its age calculations overflows, it &MUST; transmit 1042 an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches 1043 &SHOULD; use an arithmetic type of at least 31 bits of range. 1060 an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). 1061 Recipients parsing the Age header field-value &SHOULD; use an arithmetic type of 1062 at least 31 bits of range. 1044 1063 </t> 1045 1064 <t> … … 1067 1086 </t> 1068 1087 <t> 1069 HTTP/1.1 caches&MUST; obey the requirements of the Cache-Control1088 A cache &MUST; obey the requirements of the Cache-Control 1070 1089 directives defined in this section. See <xref 1071 1090 target="cache.control.extensions"/> for information about how Cache-Control … … 1080 1099 </x:note> 1081 1100 <t> 1082 Cache directives &MUST; be passed through by a proxy or gateway1083 a pplication, regardless of their significance to that application, since1084 the directives might be applicable to all recipients along the1085 request/response chain. It is not possible to target a directive to a1086 specific cache.1101 An intermediary (i.e., a proxy or gateway, whether or not it implements 1102 a cache) &MUST; pass cache directives through, regardless of their 1103 significance to that application, since the directives might be applicable 1104 to all recipients along the request/response chain. It is not possible to 1105 target a directive to a specific cache. 1087 1106 </t> 1088 1107 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="Cache-Control-v"/><iref primary="true" item="Grammar" subitem="cache-extension"/> … … 1118 1137 <iref item="no-cache" primary="true" subitem="Cache Directive" /> 1119 1138 <list> 1120 <t>The no-cache request directive indicates that a stored response1121 &MUST-NOT; be used to satisfy the request without successful validation1122 on the origin server.</t>1139 <t>The no-cache request directive indicates that a cache &MUST-NOT; 1140 use a stored response to satisfy the request without successful 1141 validation on the origin server.</t> 1123 1142 </list> 1124 1143 </t> … … 1130 1149 <t>The no-store request directive indicates that a cache &MUST-NOT; 1131 1150 store any part of either this request or any response to it. This 1132 directive applies to both non-sharedand shared caches. "&MUST-NOT;1151 directive applies to both private and shared caches. "&MUST-NOT; 1133 1152 store" in this context means that the cache &MUST-NOT; intentionally 1134 1153 store the information in non-volatile storage, and &MUST; make a … … 1185 1204 <iref item="no-transform" primary="true" subitem="Cache Directive" /> 1186 1205 <list> 1187 <t>The no-transform request directive indicates that an intermediate 1188 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1189 Content-Type request header fields, nor the request representation.</t> 1206 <t>The no-transform request directive indicates that an intermediary 1207 (whether or not it implements a cache) &MUST-NOT; change the 1208 Content-Encoding, Content-Range or Content-Type request header fields, 1209 nor the request representation.</t> 1190 1210 </list> 1191 1211 </t> … … 1200 1220 with the other constraints of the request, or respond with a 504 1201 1221 (Gateway Timeout) status code. If a group of caches is being operated as 1202 a unified system with good internal connectivity, such a request&MAY;1203 be forwardedwithin that group of caches.</t>1222 a unified system with good internal connectivity, a member cache &MAY; 1223 forward such a request within that group of caches.</t> 1204 1224 </list> 1205 1225 </t> … … 1230 1250 <iref item="public" primary="true" subitem="Cache Directive" /> 1231 1251 <list> 1232 <t>The public response directive indicates that the response &MAY; be1233 cached, even if it would normally be non-cacheable or cacheable only1234 within a non-sharedcache. (See also Authorization,1252 <t>The public response directive indicates that a cache &MAY; store 1253 the response, even if it would normally be non-cacheable or cacheable only 1254 within a private cache. (See also Authorization, 1235 1255 &header-authorization;, for additional details.) </t> 1236 1256 </list> … … 1243 1263 <t>The private response directive indicates that the response message is 1244 1264 intended for a single user and &MUST-NOT; be stored by a shared cache. A 1245 private (non-shared)cache &MAY; store the response.</t>1265 private cache &MAY; store the response.</t> 1246 1266 <t>If the private response directive specifies one or more field-names, 1247 1267 this requirement is limited to the field-values associated with the 1248 listed response header fields. That is, the specified field-names(s)1249 &MUST-NOT; be stored by a shared cache, whereasthe remainder of the1250 response message &MAY; be.</t>1268 listed response header fields. That is, a shared cache &MUST-NOT; store 1269 the specified field-names(s), whereas it &MAY; store the remainder of the 1270 response message.</t> 1251 1271 <t> <x:h>Note:</x:h> This usage of the word private only controls where 1252 1272 the response can be stored; it cannot ensure the privacy of the message … … 1269 1289 <t>If the no-cache response directive specifies one or more field-names, 1270 1290 this requirement is limited to the field-values associated with the 1271 listed response header fields. That is, the specified field-name(s) &MUST-NOT;1272 be sentin the response to a subsequent request without successful1291 listed response header fields. That is, a cache &MUST-NOT; send the 1292 specified field-name(s) in the response to a subsequent request without successful 1273 1293 validation on the origin server. This allows an origin server to prevent 1274 1294 the re-use of certain header fields in a response, while still allowing … … 1288 1308 <t>The no-store response directive indicates that a cache &MUST-NOT; 1289 1309 store any part of either the immediate request or response. This 1290 directive applies to both non-sharedand shared caches. "&MUST-NOT;1310 directive applies to both private and shared caches. "&MUST-NOT; 1291 1311 store" in this context means that the cache &MUST-NOT; intentionally 1292 1312 store the information in non-volatile storage, and &MUST; make a … … 1305 1325 <list> 1306 1326 <t>The must-revalidate response directive indicates that once it has 1307 become stale, the response &MUST-NOT; be usedto satisfy subsequent1327 become stale, a cache &MUST-NOT; use the response to satisfy subsequent 1308 1328 requests without successful validation on the origin server.</t> 1309 1329 <t>The must-revalidate directive is necessary to support reliable 1310 operation for certain protocol features. In all circumstances a n1311 HTTP/1.1cache &MUST; obey the must-revalidate directive; in particular,1312 if thecache cannot reach the origin server for any reason, it &MUST;1330 operation for certain protocol features. In all circumstances a 1331 cache &MUST; obey the must-revalidate directive; in particular, 1332 if a cache cannot reach the origin server for any reason, it &MUST; 1313 1333 generate a 504 (Gateway Timeout) response.</t> 1314 <t> Servers&SHOULD; send the must-revalidate directive if and only if1334 <t>A server &SHOULD; send the must-revalidate directive if and only if 1315 1335 failure to validate a request on the representation could result in 1316 1336 incorrect operation, such as a silently unexecuted financial … … 1325 1345 <t>The proxy-revalidate response directive has the same meaning as the 1326 1346 must-revalidate response directive, except that it does not apply to 1327 non-sharedcaches.</t>1347 private caches.</t> 1328 1348 </list> 1329 1349 </t> … … 1355 1375 <iref item="no-transform" primary="true" subitem="Cache Directive" /> 1356 1376 <list> 1357 <t>The no-transform response directive indicates that an intermediate 1358 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1359 Content-Type response header fields, nor the response representation.</t> 1377 <t>The no-transform response directive indicates that an intermediary 1378 (regardless of whether it implements a cache) &MUST-NOT; change the 1379 Content-Encoding, Content-Range or Content-Type response header fields, 1380 nor the response representation.</t> 1360 1381 </list> 1361 1382 </t> … … 1387 1408 For example, consider a hypothetical new response directive called 1388 1409 "community" that acts as a modifier to the private directive. We define 1389 this new directive to mean that, in addition to any non-sharedcache, any1410 this new directive to mean that, in addition to any private cache, any 1390 1411 cache that is shared only by members of the community named within its 1391 1412 value may cache the response. An origin server wishing to allow the UCI … … 1402 1423 </t> 1403 1424 <t> 1404 Unrecognized cache directives &MUST; be ignored; it is assumed that any1425 A cache &MUST; be ignore unrecognized cache directives; it is assumed that any 1405 1426 cache directive likely to be unrecognized by an HTTP/1.1 cache will be 1406 1427 combined with standard directives (or the response's default cacheability) … … 1413 1434 </t> 1414 1435 <t> 1415 Registrations&MUST; include the following fields:1436 A registration &MUST; include the following fields: 1416 1437 <list style="symbols"> 1417 1438 <t>Cache Directive Name</t> … … 1447 1468 <t> 1448 1469 The field-value is an absolute date and time as defined by HTTP-date in 1449 &full-date;; it &MUST; be sent inrfc1123-date format.1470 &full-date;; a sender &MUST; use the rfc1123-date format. 1450 1471 </t> 1451 1472 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/><iref primary="true" item="Grammar" subitem="Expires-v"/> … … 1467 1488 </x:note> 1468 1489 <t> 1469 HTTP/1.1 servers&SHOULD-NOT; send Expires dates more than one year in the1490 A server &SHOULD-NOT; send Expires dates more than one year in the 1470 1491 future. 1471 1492 </t> 1472 1493 <t> 1473 HTTP/1.1 clients and caches&MUST; treat other invalid date formats,1494 A cache &MUST; treat other invalid date formats, 1474 1495 especially including the value "0", as in the past (i.e., "already 1475 1496 expired"). … … 1498 1519 </artwork></figure> 1499 1520 <t> 1500 When the no-cache directive is present in a request message, a n application1521 When the no-cache directive is present in a request message, a cache 1501 1522 &SHOULD; forward the request toward the origin server even if it has a 1502 cached copy of what is being requested. This pragma directive has the same1523 stored copy of what is being requested. This pragma directive has the same 1503 1524 semantics as the no-cache response directive (see <xref 1504 1525 target="cache-response-directive" />) and is defined here for backward 1505 compatibility with HTTP/1.0. Clients&SHOULD; include both header fields1526 compatibility with HTTP/1.0. A client &SHOULD; include both header fields 1506 1527 when a no-cache request is sent to a server not known to be HTTP/1.1 1507 compliant. HTTP/1.1 caches&SHOULD; treat "Pragma: no-cache" as if the1528 compliant. A cache &SHOULD; treat "Pragma: no-cache" as if the 1508 1529 client had sent "Cache-Control: no-cache". 1509 1530 </t> … … 1551 1572 </t> 1552 1573 <t> 1553 Servers&SHOULD; include a Vary header field with any cacheable response1574 A server &SHOULD; include a Vary header field with any cacheable response 1554 1575 that is subject to server-driven negotiation. Doing so allows a cache to 1555 1576 properly interpret future requests on that resource and informs the user … … 1564 1585 to the request-header fields (e.g., the network address of the client), play a 1565 1586 role in the selection of the response representation; therefore, a cache 1566 cannot determine whether this response is appropriate. The "*" value1567 &MUST-NOT; be generated by a proxy server.1587 cannot determine whether this response is appropriate. A proxy &MUST-NOT; 1588 generate the "*" value. 1568 1589 </t> 1569 1590 <t> … … 1634 1655 <list style="symbols"> 1635 1656 <t>1xx Warnings describe the freshness or validation status of the 1636 response, and so &MUST; be deleted by cachesafter validation. They can1657 response, and so &MUST; be deleted by a cache after validation. They can 1637 1658 only be generated by a cache when validating a cached entry, and 1638 1659 &MUST-NOT; be generated in any other situation.</t> 1639 1660 <t>2xx Warnings describe some aspect of the representation that is not 1640 1661 rectified by a validation (for example, a lossy compression of the 1641 representation) and &MUST-NOT; be deleted by cachesafter validation,1662 representation) and &MUST-NOT; be deleted by a cache after validation, 1642 1663 unless a full response is returned, in which case they &MUST; be.</t> 1643 1664 </list> … … 1650 1671 </t> 1651 1672 <t> 1652 If a n implementationreceives a message with a warning-value that includes1673 If a system receives a message with a warning-value that includes 1653 1674 a warn-date, and that warn-date is different from the Date value in the 1654 1675 response, then that warning-value &MUST; be deleted from the message before … … 1664 1685 110 Response is stale 1665 1686 <list> 1666 <t> &SHOULD; be includedwhenever the returned response is stale.</t>1687 <t>A cache &SHOULD; include this whenever the returned response is stale.</t> 1667 1688 </list> 1668 1689 </t> … … 1670 1691 111 Revalidation failed 1671 1692 <list> 1672 <t> &SHOULD; be included if a cache returnsa stale response because an1693 <t>A cache &SHOULD; include this when returning a stale response because an 1673 1694 attempt to validate the response failed, due to an inability to reach 1674 1695 the server.</t> … … 1678 1699 112 Disconnected operation 1679 1700 <list> 1680 <t> &SHOULD; be included if the cacheis intentionally disconnected from1701 <t>A cache &SHOULD; b include this if it is intentionally disconnected from 1681 1702 the rest of the network for a period of time.</t> 1682 1703 </list> … … 1685 1706 113 Heuristic expiration 1686 1707 <list> 1687 <t> &SHOULD; be included if the cacheheuristically chose a freshness1708 <t>A cache &SHOULD; include this if it heuristically chose a freshness 1688 1709 lifetime greater than 24 hours and the response's age is greater than 24 1689 1710 hours.</t> … … 1701 1722 214 Transformation applied 1702 1723 <list> 1703 <t>&MUST; be added by a n intermediateproxy if it applies any1724 <t>&MUST; be added by a proxy if it applies any 1704 1725 transformation to the representation, such as changing the 1705 1726 content-coding, media-type, or modifying the representation data, unless
Note: See TracChangeset
for help on using the changeset viewer.