![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 608 for draft-ietf-httpbis/07/draft-ietf-httpbis-p6-cache-07.txt
- Timestamp:
- 13/07/09 06:58:01 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/07/draft-ietf-httpbis-p6-cache-07.txt
r605 r608 179 179 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 180 180 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 181 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5181 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 182 182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 183 183 … … 731 731 2.4. Validation Model 732 732 733 Checking with the origin server to see if a stale or otherwise734 unusable cached response can be reused is called "validating"or735 "revalidating." Doing so potentially avoids the overhead of733 When a cache has one or more stored responses for a requested URI, 734 but cannot serve any of them (e.g., because they are not fresh, or 735 one cannot be selected; see Section 2.6), it can use the conditional 736 736 737 737 … … 743 743 744 744 745 retransmitting the response body when the stored response is valid. 746 747 HTTP's conditional request mechanism [Part4] is used for this 748 purpose. When a stored response includes one or more validators, 749 such as the field values of an ETag or Last-Modified header field, 750 then a validating request SHOULD be made conditional to those field 751 values. 745 request mechanism [Part4] in the forwarded request to give the origin 746 server an opportunity to both select a valid stored response to be 747 used, and to update it. This process is known as "validating" or 748 "revalidating" the stored response. 749 750 When sending such a conditional request, the cache SHOULD add an If- 751 Modified-Since header whose value is that of the Last-Modified header 752 from the selected (see Section 2.6) stored response, if available. 753 754 Additionally, the cache SHOULD add an If-None-Match header whose 755 value is that of the ETag header(s) from all responses stored for the 756 requested URI, if present. However, if any of the stored responses 757 contains only partial content, its entity-tag SHOULD NOT be included 758 in the If-None-Match header field unless the request is for a range 759 that would be fully satisfied by that stored response. 752 760 753 761 A 304 (Not Modified) response status code indicates that the stored 754 762 response can be updated and reused; see Section 2.7. 755 763 756 If instead the cache receives a full response (i.e., one with a 757 response body), it is used to satisfy the request and replace the 758 stored response. [[anchor5: Should there be a requirement here?]] 764 A full response (i.e., one with a response body) indicates that none 765 of the stored responses nominated in the conditional request is 766 suitable. Instead, the full response is used both to satisfy the 767 request and replace the stored response. [[anchor5: Should there be a 768 requirement here?]] 759 769 760 770 If a cache receives a 5xx response while attempting to validate a 761 771 response, it MAY either forward this response to the requesting 762 772 client, or act as if the server failed to respond. In the latter 763 case, it MAY return a previously stored response (which SHOULD 764 include the 111 warn-code; see Section 3.6) unless the stored 765 response includes the "must-revalidate" cache directive (see 766 Section 2.3.3). 767 768 2.5. Request Methods that Invalidate 769 770 Because unsafe methods (Section 7.1.1 of [Part2]) have the potential 771 for changing state on the origin server, intervening caches can use 772 them to keep their contents up-to-date. 773 774 The following HTTP methods MUST cause a cache to invalidate the 775 Request-URI as well as the URI(s) in the Location and Content- 776 Location headers (if present): 777 778 o PUT 779 780 o DELETE 781 782 o POST 783 784 An invalidation based on a URI from a Location or Content-Location 785 header MUST NOT be performed if the host part of that URI differs 786 from the host part in the Request-URI. This helps prevent denial of 787 service attacks. 788 789 [[anchor6: TODO: "host part" needs to be specified better.]] 790 791 A cache that passes through requests for methods it does not 792 understand SHOULD invalidate the Request-URI. 793 794 795 796 Fielding, et al. Expires January 14, 2010 [Page 14] 797 798 799 Internet-Draft HTTP/1.1, Part 6 July 2009 800 801 802 Here, "invalidate" means that the cache will either remove all stored 803 responses related to the Request-URI, or will mark these as "invalid" 804 and in need of a mandatory validation before they can be returned in 805 response to a subsequent request. 806 807 Note that this does not guarantee that all appropriate responses are 808 invalidated. For example, the request that caused the change at the 809 origin server might not have gone through the cache where a response 810 is stored. 811 812 [[anchor7: TODO: specify that only successful (2xx, 3xx?) responses 813 invalidate.]] 814 815 2.6. Caching Negotiated Responses 816 817 Use of server-driven content negotiation (Section 4.1 of [Part3]) 818 alters the conditions under which a cache can use the response for 819 subsequent requests. 820 821 When a cache receives a request that can be satisfied by a stored 822 response that includes a Vary header field (Section 3.5), it MUST NOT 823 use that response unless all of the selecting request-headers in the 824 presented request match the corresponding stored request-headers from 825 the original request. 826 827 The selecting request-headers from two requests are defined to match 828 if and only if the selecting request-headers in the first request can 829 be transformed to the selecting request-headers in the second request 830 by adding or removing linear white space [[anchor8: [ref]]] at places 831 where this is allowed by the corresponding ABNF, and/or combining 832 multiple message-header fields with the same field name following the 833 rules about message headers in Section 4.2 of [Part1]. [[DISCUSS- 834 header-specific-canonicalization: Should the matching requirement be 835 relaxed so that it would be ok to use a cached response if the 836 selecting request headers match after header-specific 837 canonicalization? (see 838 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147>)]] 839 840 A Vary header field-value of "*" always fails to match, and 841 subsequent requests to that resource can only be properly interpreted 842 by the origin server. 843 844 If no stored response matches, the cache MAY forward the presented 845 request to the origin server in a conditional request, and SHOULD 846 include all ETags stored with potentially suitable responses in an 847 If-None-Match request header. If the server responds with 304 (Not 848 Modified) and includes an entity tag or Content-Location that 849 indicates the entity to be used, that cached response MUST be used to 850 851 852 853 Fielding, et al. Expires January 14, 2010 [Page 15] 854 855 856 Internet-Draft HTTP/1.1, Part 6 July 2009 857 858 859 satisfy the presented request, and SHOULD be used to update the 860 corresponding stored response; see Section 2.7. 861 862 If any of the stored responses contains only partial content, its 863 entity-tag SHOULD NOT be included in the If-None-Match header field 864 unless the request is for a range that would be fully satisfied by 865 that stored response. 773 case, it MAY return a previously stored response (see Section 2.3.3). 866 774 867 775 If a cache receives a successful response whose Content-Location … … 870 778 stored response, and whose Date is more recent than that of the 871 779 existing response, the existing response SHOULD NOT be returned in 872 response to future requests and SHOULD be deleted from the 873 cache.[[anchor9: DISCUSS: Not sure if this is necessary.]] 780 response to future requests and SHOULD be deleted from the cache. 781 [[anchor6: DISCUSS: Not sure if this is necessary.]] 782 783 2.5. Request Methods that Invalidate 784 785 Because unsafe methods (Section 7.1.1 of [Part2]) have the potential 786 for changing state on the origin server, intervening caches can use 787 them to keep their contents up-to-date. 788 789 The following HTTP methods MUST cause a cache to invalidate the 790 Request-URI as well as the URI(s) in the Location and Content- 791 Location headers (if present): 792 793 794 795 796 Fielding, et al. Expires January 14, 2010 [Page 14] 797 798 799 Internet-Draft HTTP/1.1, Part 6 July 2009 800 801 802 o PUT 803 804 o DELETE 805 806 o POST 807 808 An invalidation based on a URI from a Location or Content-Location 809 header MUST NOT be performed if the host part of that URI differs 810 from the host part in the Request-URI. This helps prevent denial of 811 service attacks. 812 813 [[anchor7: TODO: "host part" needs to be specified better.]] 814 815 A cache that passes through requests for methods it does not 816 understand SHOULD invalidate the Request-URI. 817 818 Here, "invalidate" means that the cache will either remove all stored 819 responses related to the Request-URI, or will mark these as "invalid" 820 and in need of a mandatory validation before they can be returned in 821 response to a subsequent request. 822 823 Note that this does not guarantee that all appropriate responses are 824 invalidated. For example, the request that caused the change at the 825 origin server might not have gone through the cache where a response 826 is stored. 827 828 [[anchor8: TODO: specify that only successful (2xx, 3xx?) responses 829 invalidate.]] 830 831 2.6. Caching Negotiated Responses 832 833 When a cache receives a request that can be satisfied by a stored 834 response that has a Vary header field (Section 3.5), it MUST NOT use 835 that response unless all of the selecting request-headers nominated 836 by the Vary header match in both the original request (i.e., that 837 associated with the stored response), and the presented request. 838 839 The selecting request-headers from two requests are defined to match 840 if and only if the selecting request-headers in the first request can 841 be transformed to the selecting request-headers in the second request 842 by adding or removing linear white space [[anchor9: [ref]]] at places 843 where this is allowed by the corresponding ABNF, and/or combining 844 multiple message-header fields with the same field name following the 845 rules about message headers in Section 4.2 of [Part1]. 846 847 If a header field is absent from a request, it can only match another 848 request if it is also absent there. 849 850 851 852 853 Fielding, et al. Expires January 14, 2010 [Page 15] 854 855 856 Internet-Draft HTTP/1.1, Part 6 July 2009 857 858 859 A Vary header field-value of "*" always fails to match, and 860 subsequent requests to that resource can only be properly interpreted 861 by the origin server. 862 863 The stored response with matching selecting request-headers is known 864 as the selected response. 865 866 If no selected response is available, the cache MAY forward the 867 presented request to the origin server in a conditional request; see 868 Section 2.4. 874 869 875 870 2.7. Combining Responses 876 871 877 872 When a cache receives a 304 (Not Modified) response or a 206 (Partial 878 Content) response, it needs to update the stored response with the 879 new one, so that the updated response can be sent to the client. 880 881 If the status code is 304 (Not Modified), the cache SHOULD use the 882 stored entity-body as the updated entity-body. If the status code is 883 206 (Partial Content) and the ETag or Last-Modified headers match 884 exactly, the cache MAY combine the stored entity-body in the stored 885 response with the updated entity-body received in the response and 886 use the result as the updated entity-body (see Section 4 of [Part5]). 887 888 The stored response headers are used for the updated response, except 889 that 873 Content) response (in this section, the "new" response"), it needs to 874 created an updated response by combining the stored response with the 875 new one, so that the updated response can be used to satisfy the 876 request. 877 878 If the new response contains an ETag, it identifies the stored 879 response to use. [[anchor10: may need language about Content-Location 880 here]][[anchor11: cover case where INM with multiple etags was sent]] 881 882 If the status code is 206 (partial content), both the stored and new 883 responses MUST have ETags, and those ETags MUST match using the 884 strong comparison function (see Section 4 of [Part4]). Otherwise, 885 the responses MUST NOT be combined. 886 887 The stored response headers are used as those of the updated 888 response, except that 890 889 891 890 o any stored Warning headers with warn-code 1xx (see Section 3.6) 892 MUST be deleted from the stored response and the forwarded 893 response. 891 MUST be deleted from the stored response and the updated response. 894 892 895 893 o any stored Warning headers with warn-code 2xx MUST be retained in 896 the stored response and the forwarded response.897 898 o any headers provided in the 304 or 206response MUST replace the894 the stored response and the updated response. 895 896 o any headers provided in the new response MUST replace the 899 897 corresponding headers from the stored response. 900 898 901 A cache MUST also replace any stored headers with corresponding 902 headers received in the incoming response, except for Warning headers 903 as described immediately above. If a header field-name in the 904 incoming response matches more than one header in the stored 905 response, all such old headers MUST be replaced. It MAY store the 906 combined entity-body. 899 If a header field-name in the new response matches more than one 900 header in the stored response, all such stored headers MUST be 901 replaced. 902 903 The updated response can [[[[anchor12: requirement?]]]] be used to 904 replace the stored response in cache. In the case of a 206 response, 905 the combined entity-body MAY be stored. 906 907 907 908 908 … … 914 914 915 915 916 [[anchor1 0: ISSUE: discuss how to handle HEAD updates]]916 [[anchor13: ISSUE: discuss how to handle HEAD updates]] 917 917 918 918 … … 1045 1045 by no more than the specified number of seconds. If no value is 1046 1046 assigned to max-stale, then the client is willing to accept a 1047 stale response of any age. [[anchor1 1: of any staleness? --mnot]]1047 stale response of any age. [[anchor14: of any staleness? --mnot]] 1048 1048 1049 1049 min-fresh … … 1728 1728 transfer encoding that may not be self delimiting); it was important 1729 1729 to straighten out exactly how message lengths are computed. (see also 1730 [Part1], [Part3] and [Part5]) [[anchor1 4: This used to refer to the1730 [Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the 1731 1731 text about non-modifiable headers, and will have to be updated later 1732 1732 on. --jre]] 1733 1733 1734 1734 Proxies should be able to add Content-Length when appropriate. 1735 [[anchor1 5: This used to refer to the text about non-modifiable1735 [[anchor18: This used to refer to the text about non-modifiable 1736 1736 headers, and will have to be updated later on. --jre]] 1737 1737 … … 1984 1984 numeric protocol elements" 1985 1985 1986 Affected issues: 1987 1988 o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- 1989 existant headers 1990 1991 1992 1993 Fielding, et al. Expires January 14, 2010 [Page 35] 1994 1995 1996 Internet-Draft HTTP/1.1, Part 6 July 2009 1997 1986 1998 1987 1999 Index 1988 2000 1989 2001 A 1990 1991 1992 1993 Fielding, et al. Expires January 14, 2010 [Page 35]1994 1995 1996 Internet-Draft HTTP/1.1, Part 6 July 20091997 1998 1999 2002 age 6 2000 2003 Age header 17 … … 2042 2045 Pragma 24 2043 2046 pragma-directive 24 2047 2048 2049 2050 Fielding, et al. Expires January 14, 2010 [Page 36] 2051 2052 2053 Internet-Draft HTTP/1.1, Part 6 July 2009 2054 2055 2044 2056 Pragma-v 24 2045 2057 Vary 24 2046 2058 Vary-v 24 2047 2048 2049 2050 Fielding, et al. Expires January 14, 2010 [Page 36]2051 2052 2053 Internet-Draft HTTP/1.1, Part 6 July 20092054 2055 2056 2059 warn-agent 25 2057 2060 warn-code 25 … … 2099 2102 Cache Directive 20 2100 2103 proxy-revalidate 2104 2105 2106 2107 Fielding, et al. Expires January 14, 2010 [Page 37] 2108 2109 2110 Internet-Draft HTTP/1.1, Part 6 July 2009 2111 2112 2101 2113 Cache Directive 21 2102 2114 public 2103 2115 Cache Directive 20 2104 2105 2106 2107 Fielding, et al. Expires January 14, 2010 [Page 37]2108 2109 2110 Internet-Draft HTTP/1.1, Part 6 July 20092111 2112 2116 2113 2117 S … … 2146 2150 Email: jg@laptop.org 2147 2151 URI: http://www.laptop.org/ 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 Fielding, et al. Expires January 14, 2010 [Page 38] 2165 2166 2167 Internet-Draft HTTP/1.1, Part 6 July 2009 2148 2168 2149 2169 … … 2156 2176 2157 2177 Email: JeffMogul@acm.org 2158 2159 2160 2161 2162 2163 2164 Fielding, et al. Expires January 14, 2010 [Page 38]2165 2166 2167 Internet-Draft HTTP/1.1, Part 6 July 20092168 2178 2169 2179 … … 2209 2219 2210 2220 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2221 Fielding, et al. Expires January 14, 2010 [Page 39] 2222 2222
Note: See TracChangeset
for help on using the changeset viewer.
