Changeset 1375 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 04/08/11 05:44:42 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1373 r1375 556 556 </li> 557 557 <li>2. <a href="#caching.overview">Cache Operation</a><ul> 558 <li>2.1 <a href="#response.cacheability">Response Cacheability</a><ul> 559 <li>2.1.1 <a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li> 560 </ul> 561 </li> 558 <li>2.1 <a href="#response.cacheability">Response Cacheability</a></li> 562 559 <li>2.2 <a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li> 563 560 <li>2.3 <a href="#expiration.model">Freshness Model</a><ul> … … 574 571 <li>2.6 <a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li> 575 572 <li>2.7 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 576 <li>2.8 <a href="#combining.responses">Combining Responses</a></li> 573 <li>2.8 <a href="#combining.responses">Combining Partial Content</a></li> 574 <li>2.9 <a href="#freshening.responses">Freshening Responses</a></li> 577 575 </ul> 578 576 </li> … … 639 637 Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel. 640 638 </p> 641 <p id="rfc.section.1.1.p.2"> Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior642 re sponse message to satisfy a current request. In some cases, a stored response can be reused without the need for a network643 request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section 2.3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy644 the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section 2.4</a>).639 <p id="rfc.section.1.1.p.2">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current 640 request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains 641 valid for this request). A fresh cache response can therefore reduce both latency and network transfers each time it is reused. 642 When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation Model">Section 2.4</a>) or if the origin is unavailable. 645 643 </p> 646 644 <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> … … 657 655 </p> 658 656 <ul class="empty"> 659 <li>A cache that is accessible tomore than one user; usually (but not always) deployed as part of an intermediary.</li>657 <li>A cache that stores responses to be reused by more than one user; usually (but not always) deployed as part of an intermediary.</li> 660 658 </ul> 661 659 </div> … … 712 710 <ul class="empty"> 713 711 <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 714 equivalent copy of a representation. 712 equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 713 </li> 714 </ul> 715 <p id="rfc.section.1.2.p.14"> <span id="rfc.iref.s.3"></span> <span id="rfc.iref.v.2"></span> <dfn>strong validator</dfn> 716 </p> 717 <ul class="empty"> 718 <li>A validator that is defined by the origin server such that its current value will change if the representation body changes; 719 i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 715 720 </li> 716 721 </ul> … … 750 755 its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648. 751 756 </p> 757 <div id="rfc.iref.c.4"></div> 758 <div id="rfc.iref.c.5"></div> 752 759 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Cache Operation</a></h1> 760 <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when 761 no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing 762 a cache from either storing a non-reusable response or reusing a stored response inappropriately. 763 </p> 764 <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common 765 form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of 766 the resource identified by the request target. However, it is also possible to cache negative results (e.g., 404 not found), 767 incomplete results (e.g., 206 partial content), and responses to safe methods other than GET if the method's definition allows 768 such caching and defines something suitable for use as a cache key. 769 </p> 770 <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching 771 responses to GET, most implementations simply decline other methods and use only the URI as the key. 772 </p> 773 <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated 774 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>). 775 </p> 753 776 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2> 754 777 <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: … … 779 802 <p id="rfc.section.2.1.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a>. 780 803 </p> 781 <p id="rfc.section.2.1.p.3">In this context, a cache has "understood" a request method or a response status code if it recognises it and implements any 782 cache-specific behavior. In particular, 206 Partial Content responses cannot be cached by an implementation that does not 783 handle partial content (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a>). 784 </p> 785 <p id="rfc.section.2.1.p.4">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration 804 <p id="rfc.section.2.1.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements any 805 cache-specific behavior. 806 </p> 807 <p id="rfc.section.2.1.p.4">Note that, in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration 786 808 time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 787 809 </p> 788 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3> 789 <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header 790 field) can store the response, but <em class="bcp14">MUST</em> treat it as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses can be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code. 791 </p> 792 <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> store incomplete or partial responses. 810 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 811 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message-body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) 812 response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 813 not understand the range units used in those fields. 814 </p> 815 <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 2.8</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies 816 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code. 793 817 </p> 794 818 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2> … … 796 820 </p> 797 821 <ul> 798 <li>The presented 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.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and822 <li>The presented 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.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and 799 823 </li> 800 824 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 818 842 <p id="rfc.section.2.2.p.3">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>. 819 843 </p> 820 <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 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 and844 <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><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 821 845 having received a corresponding response. 822 846 </p> … … 869 893 <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> 870 894 <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 871 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.895 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.3"><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. 872 896 </p> 873 897 <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 874 898 is not already present. 875 899 </p> 876 <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 2.1</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 this900 <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 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.4"><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 877 901 fraction might be 10%. 878 902 </p> … … 901 925 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 902 926 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 903 operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.927 operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.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> for the definition of the Date header field, and for requirements regarding responses without it. 904 928 </li> 905 929 </ul> … … 958 982 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> 959 983 <p id="rfc.section.2.4.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 960 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4. 2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to984 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 961 985 update it. This process is known as "validating" or "revalidating" the stored response. 962 986 </p> … … 967 991 that stored response. 968 992 </p> 969 <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>.993 <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="#freshening.responses" title="Freshening Responses">Section 2.9</a>. 970 994 </p> 971 995 <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 972 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 .996 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(s). 973 997 </p> 974 998 <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>). 975 999 </p> 976 1000 <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> 977 <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>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them1001 <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.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them 978 1002 to keep their contents up-to-date. 979 1003 </p> 980 <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.1 3"><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 a non-error response to a request1004 <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.14"><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 a non-error response to a request 981 1005 with an unsafe method is received. 982 1006 </p> 983 1007 <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 984 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.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.985 </p> 986 <p id="rfc.section.2.5.p.4">A cache <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.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.1008 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.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1009 </p> 1010 <p id="rfc.section.2.5.p.4">A cache <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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 987 1011 </p> 988 1012 <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all … … 1011 1035 <ul> 1012 1036 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 1013 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)1037 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 1014 1038 </li> 1015 1039 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1028 1052 <p id="rfc.section.2.7.p.7">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section 2.4</a>. 1029 1053 </p> 1030 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="combining.responses" href="#combining.responses">Combining Responses</a></h2> 1031 <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), 1032 it needs to create an updated response by combining the stored response with the new one, so that the updated response can 1033 be used to satisfy the request, and potentially update the cached response. 1034 </p> 1035 <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> 1036 </p> 1037 <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 versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1038 </p> 1039 <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p> 1040 <ul> 1041 <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>). 1042 </li> 1043 <li>a cache <em class="bcp14">MUST</em> retain any stored Warning header fields with warn-code 2xx. 1044 </li> 1045 <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 1046 stored response. 1047 </li> 1048 </ul> 1049 <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 1050 the case of a 206 response, a cache <em class="bcp14">MAY</em> store the combined representation. 1051 </p> 1054 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2> 1055 <p id="rfc.section.2.8.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1056 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1057 same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1058 </p> 1059 <p id="rfc.section.2.8.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: 1060 </p> 1061 <ul> 1062 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>); 1063 </li> 1064 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> 1065 <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 1066 header fields in the stored response. 1067 </li> 1068 </ul> 1069 <h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses</a></h2> 1070 <p id="rfc.section.2.9.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache 1071 key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored 1072 response(s) with the new information provided in the 304 response. 1073 </p> 1074 <ul> 1075 <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of 1076 the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong 1077 validator, then this new response corresponds to a new selected representation and <em class="bcp14">MUST NOT</em> update the existing stored responses. 1078 </li> 1079 <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then 1080 the most recent of those matching stored responses is selected. 1081 </li> 1082 <li>If the new response does not include any form of validator, there is only one stored response, and that stored response also 1083 lacks a validator, then that stored response is selected. 1084 </li> 1085 </ul> 1086 <p id="rfc.section.2.9.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 1087 </p> 1088 <ul> 1089 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a>); 1090 </li> 1091 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> 1092 <li>use other header fields provided in the 304 response to replace all instances of the corresponding header fields in the stored 1093 response. 1094 </li> 1095 </ul> 1052 1096 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1053 1097 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> … … 1064 1108 true, since HTTP/1.0 caches might not implement the Age header field. 1065 1109 </p> 1066 <div id="rfc.iref.c. 4"></div>1110 <div id="rfc.iref.c.6"></div> 1067 1111 <div id="rfc.iref.h.3"></div> 1068 1112 <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> … … 1097 1141 / "only-if-cached" 1098 1142 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1099 </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>1143 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.1"></span> 1100 1144 </p> 1101 1145 <ul class="empty"> … … 1103 1147 </li> 1104 1148 </ul> 1105 <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>1149 <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.n.2"></span> 1106 1150 </p> 1107 1151 <ul class="empty"> … … 1115 1159 </li> 1116 1160 </ul> 1117 <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>1161 <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> 1118 1162 </p> 1119 1163 <ul class="empty"> … … 1122 1166 </li> 1123 1167 </ul> 1124 <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>1168 <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> 1125 1169 </p> 1126 1170 <ul class="empty"> … … 1131 1175 </li> 1132 1176 </ul> 1133 <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>1177 <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> 1134 1178 </p> 1135 1179 <ul class="empty"> … … 1139 1183 </li> 1140 1184 </ul> 1141 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c.1 0"></span> <span id="rfc.iref.n.3"></span>1185 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.n.3"></span> 1142 1186 </p> 1143 1187 <ul class="empty"> … … 1145 1189 </li> 1146 1190 </ul> 1147 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.1 1"></span> <span id="rfc.iref.o.1"></span>1191 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> 1148 1192 </p> 1149 1193 <ul class="empty"> … … 1166 1210 / "s-maxage" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a> 1167 1211 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1168 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.1 2"></span> <span id="rfc.iref.p.2"></span>1212 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.p.2"></span> 1169 1213 </p> 1170 1214 <ul class="empty"> … … 1172 1216 </li> 1173 1217 </ul> 1174 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.1 3"></span> <span id="rfc.iref.p.3"></span>1218 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> 1175 1219 </p> 1176 1220 <ul class="empty"> … … 1185 1229 </li> 1186 1230 </ul> 1187 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.1 4"></span> <span id="rfc.iref.n.4"></span>1231 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.4"></span> 1188 1232 </p> 1189 1233 <ul class="empty"> … … 1202 1246 </li> 1203 1247 </ul> 1204 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.1 5"></span> <span id="rfc.iref.n.5"></span>1248 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.n.5"></span> 1205 1249 </p> 1206 1250 <ul class="empty"> … … 1211 1255 </li> 1212 1256 </ul> 1213 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.1 6"></span> <span id="rfc.iref.m.4"></span>1257 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.m.4"></span> 1214 1258 </p> 1215 1259 <ul class="empty"> … … 1223 1267 </li> 1224 1268 </ul> 1225 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.1 7"></span> <span id="rfc.iref.p.4"></span>1269 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.p.4"></span> 1226 1270 </p> 1227 1271 <ul class="empty"> … … 1230 1274 </li> 1231 1275 </ul> 1232 <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>1276 <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn> <span id="rfc.iref.c.20"></span> <span id="rfc.iref.m.5"></span> 1233 1277 </p> 1234 1278 <ul class="empty"> … … 1237 1281 </li> 1238 1282 </ul> 1239 <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>1283 <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn> <span id="rfc.iref.c.21"></span> <span id="rfc.iref.s.4"></span> 1240 1284 </p> 1241 1285 <ul class="empty"> … … 1245 1289 </li> 1246 1290 </ul> 1247 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c.2 0"></span> <span id="rfc.iref.n.6"></span>1291 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c.22"></span> <span id="rfc.iref.n.6"></span> 1248 1292 </p> 1249 1293 <ul class="empty"> … … 1295 1339 that time. 1296 1340 </p> 1297 <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.1 7"><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.1341 <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.18"><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. 1298 1342 </p> 1299 1343 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> … … 1339 1383 </p> 1340 1384 </div> 1341 <div id="rfc.iref.v. 2"></div>1385 <div id="rfc.iref.v.3"></div> 1342 1386 <div id="rfc.iref.h.6"></div> 1343 1387 <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> … … 1605 1649 <td class="left">http</td> 1606 1650 <td class="left">standard</td> 1607 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning. 3" title="Warning">Section 3.6</a>1651 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 3.6</a> 1608 1652 </td> 1609 1653 </tr> … … 1619 1663 </p> 1620 1664 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1621 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1665 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1622 1666 </p> 1623 1667 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1723 1767 </p> 1724 1768 <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented. 1725 (<a href="#header.warning" id="rfc.xref.header.warning. 4" title="Warning">Section 3.6</a>)1769 (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 3.6</a>) 1726 1770 </p> 1727 1771 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1997 2041 <li>Cache Directives 1998 2042 <ul> 1999 <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> 2000 <li>max-stale <a href="#rfc.iref.c.8"><b>3.2.1</b></a></li> 2001 <li>min-fresh <a href="#rfc.iref.c.9"><b>3.2.1</b></a></li> 2002 <li>must-revalidate <a href="#rfc.iref.c.16"><b>3.2.2</b></a></li> 2003 <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> 2004 <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> 2005 <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> 2006 <li>only-if-cached <a href="#rfc.iref.c.11"><b>3.2.1</b></a></li> 2007 <li>private <a href="#rfc.iref.c.13"><b>3.2.2</b></a></li> 2008 <li>proxy-revalidate <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li> 2009 <li>public <a href="#rfc.iref.c.12"><b>3.2.2</b></a></li> 2010 <li>s-maxage <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li> 2011 </ul> 2012 </li> 2013 <li>Cache-Control header field <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> 2043 <li>max-age <a href="#rfc.iref.c.9"><b>3.2.1</b></a>, <a href="#rfc.iref.c.20"><b>3.2.2</b></a></li> 2044 <li>max-stale <a href="#rfc.iref.c.10"><b>3.2.1</b></a></li> 2045 <li>min-fresh <a href="#rfc.iref.c.11"><b>3.2.1</b></a></li> 2046 <li>must-revalidate <a href="#rfc.iref.c.18"><b>3.2.2</b></a></li> 2047 <li>no-cache <a href="#rfc.iref.c.7"><b>3.2.1</b></a>, <a href="#rfc.iref.c.16"><b>3.2.2</b></a></li> 2048 <li>no-store <a href="#rfc.iref.c.8"><b>3.2.1</b></a>, <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li> 2049 <li>no-transform <a href="#rfc.iref.c.12"><b>3.2.1</b></a>, <a href="#rfc.iref.c.22"><b>3.2.2</b></a></li> 2050 <li>only-if-cached <a href="#rfc.iref.c.13"><b>3.2.1</b></a></li> 2051 <li>private <a href="#rfc.iref.c.15"><b>3.2.2</b></a></li> 2052 <li>proxy-revalidate <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li> 2053 <li>public <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li> 2054 <li>s-maxage <a href="#rfc.iref.c.21"><b>3.2.2</b></a></li> 2055 </ul> 2056 </li> 2057 <li>cache entry <a href="#rfc.iref.c.4">2</a></li> 2058 <li>cache key <a href="#rfc.iref.c.5">2</a></li> 2059 <li>Cache-Control header field <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.6"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li> 2014 2060 <li>cacheable <a href="#rfc.iref.c.3">1.2</a></li> 2015 2061 </ul> … … 2058 2104 <li>Pragma <a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.h.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li> 2059 2105 <li>Vary <a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li> 2060 <li>Warning <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc. iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.3">5.2</a>, <a href="#rfc.xref.header.warning.4">A</a></li>2106 <li>Warning <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li> 2061 2107 </ul> 2062 2108 </li> … … 2114 2160 </li> 2115 2161 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2116 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2. 2</a>, <a href="#rfc.xref.Part1.12">2.3.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.7</a>, <a href="#rfc.xref.Part1.17">3.3</a>, <a href="#rfc.xref.Part1.18">7</a>, <a href="#Part1"><b>8.1</b></a><ul>2162 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.3.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a>, <a href="#rfc.xref.Part1.17">2.7</a>, <a href="#rfc.xref.Part1.18">3.3</a>, <a href="#rfc.xref.Part1.19">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 2117 2163 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.4</a></li> 2118 2164 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a></li> 2119 2165 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li> 2120 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.1 6">2.7</a></li>2121 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 1">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li>2122 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.1 7">3.3</a></li>2123 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.1 2">2.3.2</a></li>2166 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.17">2.7</a></li> 2167 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a></li> 2168 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.18">3.3</a></li> 2169 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.13">2.3.2</a></li> 2124 2170 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2125 <li><em>Section 12</em> <a href="#rfc.xref.Part1.18">7</a></li> 2126 </ul> 2127 </li> 2128 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.2</a>, <a href="#rfc.xref.Part2.2">2.3.1.1</a>, <a href="#rfc.xref.Part2.3">2.5</a>, <a href="#Part2"><b>8.1</b></a><ul> 2129 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.1">2.2</a>, <a href="#rfc.xref.Part2.3">2.5</a></li> 2130 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">2.3.1.1</a></li> 2131 </ul> 2132 </li> 2133 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">2.3.1.1</a>, <a href="#rfc.xref.Part4.2">2.4</a>, <a href="#rfc.xref.Part4.3">2.8</a>, <a href="#Part4"><b>8.1</b></a><ul> 2134 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.1">2.3.1.1</a></li> 2135 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.3">2.8</a></li> 2136 </ul> 2137 </li> 2138 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1.1</a>, <a href="#rfc.xref.Part5.2">2.1.1</a>, <a href="#Part5"><b>8.1</b></a><ul> 2139 <li><em>Section 4</em> <a href="#rfc.xref.Part5.2">2.1.1</a></li> 2171 <li><em>Section 12</em> <a href="#rfc.xref.Part1.19">7</a></li> 2172 </ul> 2173 </li> 2174 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.3">2.3.1.1</a>, <a href="#rfc.xref.Part2.4">2.5</a>, <a href="#Part2"><b>8.1</b></a><ul> 2175 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.4">2.5</a></li> 2176 <li><em>Section 8</em> <a href="#rfc.xref.Part2.3">2.3.1.1</a></li> 2177 </ul> 2178 </li> 2179 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1.2</a>, <a href="#rfc.xref.Part4.2">1.2</a>, <a href="#rfc.xref.Part4.3">1.2</a>, <a href="#rfc.xref.Part4.4">2.3.1.1</a>, <a href="#rfc.xref.Part4.5">2.4</a>, <a href="#Part4"><b>8.1</b></a><ul> 2180 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.4">2.3.1.1</a></li> 2181 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part4.3">1.2</a></li> 2182 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.2">1.2</a></li> 2183 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.1">1.2</a></li> 2184 </ul> 2185 </li> 2186 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2.8</a>, <a href="#rfc.xref.Part5.3">2.8</a>, <a href="#Part5"><b>8.1</b></a><ul> 2187 <li><em>Section 4</em> <a href="#rfc.xref.Part5.3">2.8</a></li> 2140 2188 </ul> 2141 2189 </li> … … 2189 2237 <li>s-maxage 2190 2238 <ul> 2191 <li>Cache Directive <a href="#rfc.iref.s. 3"><b>3.2.2</b></a></li>2239 <li>Cache Directive <a href="#rfc.iref.s.4"><b>3.2.2</b></a></li> 2192 2240 </ul> 2193 2241 </li> 2194 2242 <li>shared cache <a href="#rfc.iref.s.1">1.2</a></li> 2195 2243 <li>stale <a href="#rfc.iref.s.2">1.2</a></li> 2244 <li>strong validator <a href="#rfc.iref.s.3">1.2</a></li> 2196 2245 </ul> 2197 2246 </li> 2198 2247 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2199 2248 <li>validator <a href="#rfc.iref.v.1">1.2</a></li> 2200 <li>Vary header field <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> 2249 <li>validator, strong <a href="#rfc.iref.v.2">1.2</a></li> 2250 <li>Vary header field <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> 2201 2251 </ul> 2202 2252 </li> 2203 2253 <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul> 2204 <li>Warning header field <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc. iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.3">5.2</a>, <a href="#rfc.xref.header.warning.4">A</a></li>2254 <li>Warning header field <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li> 2205 2255 </ul> 2206 2256 </li>
Note: See TracChangeset
for help on using the changeset viewer.