Changeset 1751 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 09/07/12 23:44:03 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1746 r1751 416 416 </section> 417 417 418 <section anchor="caching.overview" title=" Cache Operation">418 <section anchor="caching.overview" title="Overview of Cache Operation"> 419 419 <iref item="cache entry" /> 420 420 <iref item="cache key" /> … … 453 453 fields (<xref target="caching.negotiated.responses"/>). 454 454 </t> 455 456 <section anchor="response.cacheability" title="Response Cacheability"> 455 </section> 456 457 <section anchor="response.cacheability" title="Storing Responses in Caches"> 457 458 <t> 458 459 A cache &MUST-NOT; store a response to any request, unless: … … 503 504 prohibited from storing such responses. 504 505 </t> 506 507 <section anchor="incomplete.responses" title="Storing Incomplete Responses"> 505 508 <t> 506 509 A response message is considered complete when all of the octets indicated … … 526 529 using the <x:ref>206 (Partial Content)</x:ref> status code. 527 530 </t> 531 </section> 532 533 534 <section anchor="caching.authenticated.responses" 535 title="Storing Responses to Authenticated Requests"> 536 <t> 537 A shared cache &MUST-NOT; use a cached response to a request with an 538 <x:ref>Authorization</x:ref> header field (&header-authorization;) to 539 satisfy any subsequent request unless a cache directive that allows such 540 responses to be stored is present in the response. 541 </t> 542 543 <t> 544 In this specification, the following <x:ref>Cache-Control</x:ref> response 545 directives (<xref target="cache-response-directive"/>) have such an effect: 546 must-revalidate, public, s-maxage. 547 </t> 548 549 <t> 550 Note that cached responses that contain the "must-revalidate" and/or 551 "s-maxage" response directives are not allowed to be served stale (<xref 552 target="serving.stale.responses"/>) by shared caches. In particular, a 553 response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be 554 used to satisfy a subsequent request without revalidating it on the origin 555 server. 556 </t> 557 </section> 528 558 </section> 529 559 … … 594 624 </t> 595 625 596 </section>597 626 598 627 <section anchor="expiration.model" title="Freshness Model"> … … 682 711 responses that have invalid freshness information to be stale. 683 712 </t> 713 </section> 684 714 685 715 <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness"> … … 717 747 </t> 718 748 </x:note> 719 </section>720 749 </section> 721 750 … … 987 1016 </section> 988 1017 989 <section anchor="head.effects" title="Updating Caches with HEAD Responses">990 <t>991 A response to the HEAD method is identical to what an equivalent request992 made with a GET would have been, except it lacks a body. This property993 of HEAD responses is used to both invalidate and update cached GET994 responses.995 </t>996 <t>997 If one or more stored GET responses can be selected (as per <xref998 target="caching.negotiated.responses"/>) for a HEAD request, and the999 <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or1000 <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a1001 selected GET response, the cache &MUST; consider that selected response to1002 be stale.1003 </t>1004 <t>1005 If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and1006 <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are1007 the same as that in a selected GET response (as per1008 <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update1009 the remaining headers in the stored response using the following rules:1010 <list style="symbols">1011 <t>delete any <x:ref>Warning</x:ref> header fields in the stored response1012 with warn-code 1xx (see <xref target="header.warning" />);</t>1013 <t>retain any <x:ref>Warning</x:ref> header fields in the stored response1014 with warn-code 2xx; and,</t>1015 <t>use other header fields provided in the response to replace1016 all instances of the corresponding header fields in the stored1017 response.</t>1018 </list>1019 </t>1020 1021 </section>1022 1023 <section anchor="invalidation.after.updates.or.deletions"1024 title="Request Methods that Invalidate">1025 <t>1026 Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE1027 have the potential for changing state on the origin server, intervening1028 caches can use them to keep their contents up-to-date.1029 </t>1030 <t>1031 A cache &MUST; invalidate the effective Request URI1032 (&effective-request-uri;) as well as the URI(s) in the1033 <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header1034 fields (if present) when a non-error response to a request with an unsafe1035 method is received.1036 </t>1037 <t>1038 However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>1039 or <x:ref>Content-Location</x:ref> response header field if the host part of1040 that URI differs from the host part in the effective request URI1041 (&effective-request-uri;). This helps prevent denial of service attacks.1042 </t>1043 <t>1044 A cache &MUST; invalidate the effective request URI1045 (&effective-request-uri;) when it receives a non-error response1046 to a request with a method whose safety is unknown.1047 </t>1048 <t>1049 Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref>1050 or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that1051 the cache will either remove all stored responses related to the effective1052 request URI, or will mark these as "invalid" and in need of a mandatory1053 validation before they can be returned in response to a subsequent request.1054 </t>1055 <t>1056 Note that this does not guarantee that all appropriate responses are1057 invalidated. For example, the request that caused the change at the origin1058 server might not have gone through the cache where a response is stored.1059 </t>1060 </section>1061 1062 <section anchor="caching.authenticated.responses"1063 title="Shared Caching of Authenticated Responses">1064 <t>1065 A shared cache &MUST-NOT; use a cached response to a request with an1066 <x:ref>Authorization</x:ref> header field (&header-authorization;) to1067 satisfy any subsequent request unless a cache directive that allows such1068 responses to be stored is present in the response.1069 </t>1070 1071 <t>1072 In this specification, the following <x:ref>Cache-Control</x:ref> response1073 directives (<xref target="cache-response-directive"/>) have such an effect:1074 must-revalidate, public, s-maxage.1075 </t>1076 1077 <t>1078 Note that cached responses that contain the "must-revalidate" and/or1079 "s-maxage" response directives are not allowed to be served stale (<xref1080 target="serving.stale.responses"/>) by shared caches. In particular, a1081 response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be1082 used to satisfy a subsequent request without revalidating it on the origin1083 server.1084 </t>1085 </section>1086 1087 1018 <section anchor="caching.negotiated.responses" 1088 title=" Caching Negotiated Responses">1019 title="Using Negotiated Responses"> 1089 1020 <t> 1090 1021 When a cache receives a request that can be satisfied by a stored response … … 1142 1073 </section> 1143 1074 1075 1144 1076 <section anchor="combining.responses" title="Combining Partial Content"> 1145 1077 <t> … … 1166 1098 </t> 1167 1099 </section> 1168 1169 1170 </section> 1100 </section> 1101 1102 1103 <section anchor="head.effects" title="Updating Caches with HEAD Responses"> 1104 <t> 1105 A response to the HEAD method is identical to what an equivalent request 1106 made with a GET would have been, except it lacks a body. This property 1107 of HEAD responses is used to both invalidate and update cached GET 1108 responses. 1109 </t> 1110 <t> 1111 If one or more stored GET responses can be selected (as per <xref 1112 target="caching.negotiated.responses"/>) for a HEAD request, and the 1113 <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or 1114 <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a 1115 selected GET response, the cache &MUST; consider that selected response to 1116 be stale. 1117 </t> 1118 <t> 1119 If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and 1120 <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are 1121 the same as that in a selected GET response (as per 1122 <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update 1123 the remaining headers in the stored response using the following rules: 1124 <list style="symbols"> 1125 <t>delete any <x:ref>Warning</x:ref> header fields in the stored response 1126 with warn-code 1xx (see <xref target="header.warning" />);</t> 1127 <t>retain any <x:ref>Warning</x:ref> header fields in the stored response 1128 with warn-code 2xx; and,</t> 1129 <t>use other header fields provided in the response to replace 1130 all instances of the corresponding header fields in the stored 1131 response.</t> 1132 </list> 1133 </t> 1134 1135 </section> 1136 1137 1138 <section anchor="invalidation.after.updates.or.deletions" 1139 title="Request Methods that Invalidate"> 1140 <t> 1141 Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE 1142 have the potential for changing state on the origin server, intervening 1143 caches can use them to keep their contents up-to-date. 1144 </t> 1145 <t> 1146 A cache &MUST; invalidate the effective Request URI 1147 (&effective-request-uri;) as well as the URI(s) in the 1148 <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header 1149 fields (if present) when a non-error response to a request with an unsafe 1150 method is received. 1151 </t> 1152 <t> 1153 However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref> 1154 or <x:ref>Content-Location</x:ref> response header field if the host part of 1155 that URI differs from the host part in the effective request URI 1156 (&effective-request-uri;). This helps prevent denial of service attacks. 1157 </t> 1158 <t> 1159 A cache &MUST; invalidate the effective request URI 1160 (&effective-request-uri;) when it receives a non-error response 1161 to a request with a method whose safety is unknown. 1162 </t> 1163 <t> 1164 Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> 1165 or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that 1166 the cache will either remove all stored responses related to the effective 1167 request URI, or will mark these as "invalid" and in need of a mandatory 1168 validation before they can be returned in response to a subsequent request. 1169 </t> 1170 <t> 1171 Note that this does not guarantee that all appropriate responses are 1172 invalidated. For example, the request that caused the change at the origin 1173 server might not have gone through the cache where a response is stored. 1174 </t> 1175 </section> 1176 1177 1178 1171 1179 1172 1180 <section anchor="header.field.definitions" title="Header Field Definitions">
Note: See TracChangeset
for help on using the changeset viewer.