Changeset 908 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 24/07/10 08:30:41 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r897 r908 237 237 controls its message storage, retrieval, and deletion. A cache stores cacheable responses 238 238 in order to reduce the response time and network bandwidth consumption on future, 239 equivalent requests. Any client or server may includea cache, though a cache cannot be239 equivalent requests. Any client or server &MAY; employ a cache, though a cache cannot be 240 240 used by a server that is acting as a tunnel. 241 241 </t> … … 262 262 <list> 263 263 <t>A response is cacheable if a cache is allowed to store a copy of the response message 264 for use in answering subsequent requests. Even when a response is cacheable, there m ay264 for use in answering subsequent requests. Even when a response is cacheable, there might 265 265 be additional constraints on whether a cache can use the cached copy to satisfy a 266 266 particular request.</t> … … 537 537 assign an explicit expiration time in the past. This means that the response is always 538 538 stale, so that caches should validate it before using it for subsequent requests. 539 <cref anchor="TODO-response-stale">This wording m ay cause confusion, because the response maystill be served stale.</cref>540 </t> 541 <t> 542 Since origin servers do not always provide explicit expiration times, HTTP caches may543 a lso assign heuristic expiration times when theyare not specified, employing algorithms that539 <cref anchor="TODO-response-stale">This wording might cause confusion, because the response might still be served stale.</cref> 540 </t> 541 <t> 542 Since origin servers do not always provide explicit expiration times, HTTP caches &MAY; 543 assign heuristic expiration times when explicit times are not specified, employing algorithms that 544 544 use other header values (such as the Last-Modified time) to estimate a plausible 545 545 expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does … … 559 559 </t> 560 560 <t> 561 Additionally, clients m ayneed to influence freshness calculation. They can do this using561 Additionally, clients might need to influence freshness calculation. They can do this using 562 562 several request cache directives, with the effect of either increasing or loosening 563 563 constraints on freshness. See <xref target="cache-request-directive" />. … … 874 874 </t> 875 875 <t> 876 If (after any normali sation that maytake place) a header field is absent876 If (after any normalization that might take place) a header field is absent 877 877 from a request, it can only match another request if it is also absent there. 878 878 </t> … … 899 899 <t> 900 900 If the new response contains an ETag, it identifies the stored 901 response to use. <cref anchor="TODO-mention-CL">m ayneed language about Content-Location901 response to use. <cref anchor="TODO-mention-CL">might need language about Content-Location 902 902 here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref> 903 903 </t> … … 973 973 <t> 974 974 The presence of an Age header field in a response implies that a response is not 975 first-hand. However, the converse is not true, since HTTP/1.0 caches m aynot implement the975 first-hand. However, the converse is not true, since HTTP/1.0 caches might not implement the 976 976 Age header field. 977 977 </t> … … 1057 1057 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 1058 1058 particular, malicious or compromised caches might not recognize or obey this 1059 directive, and communications networks m aybe vulnerable to eavesdropping.</t>1059 directive, and communications networks might be vulnerable to eavesdropping.</t> 1060 1060 </list> 1061 1061 </t> … … 1159 1159 cache, whereas the remainder of the response message &MAY; be.</t> 1160 1160 <t> 1161 <x:h>Note:</x:h> This usage of the word private only controls where the response may1162 be stored , andcannot ensure the privacy of the message content.1161 <x:h>Note:</x:h> This usage of the word private only controls where the response can 1162 be stored; it cannot ensure the privacy of the message content. 1163 1163 Also, private response directives with field-names are often handled by 1164 1164 implementations as if an unqualified private directive was received; i.e., … … 1203 1203 <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In 1204 1204 particular, malicious or compromised caches might not recognize or obey this 1205 directive, and communications networks m aybe vulnerable to eavesdropping.</t>1205 directive, and communications networks might be vulnerable to eavesdropping.</t> 1206 1206 </list> 1207 1207 </t> … … 1451 1451 request-headers (e.g., the network address of the client), play a role in the selection of 1452 1452 the response representation; therefore, a cache cannot determine whether this response is 1453 appropriate. The "*" value &MUST-NOT; be generated by a proxy server; 1454 it may only be generated by an origin server. 1453 appropriate. The "*" value &MUST-NOT; be generated by a proxy server. 1455 1454 </t> 1456 1455 <t>
Note: See TracChangeset
for help on using the changeset viewer.