Changeset 172 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 23/01/08 02:11:10 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r170 r172 934 934 origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call 935 935 this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if 936 the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the937 HTTP/1.1 protocolsupports the use of conditional methods.936 the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, HTTP/1.1 937 supports the use of conditional methods. 938 938 </p> 939 939 <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server … … 1029 1029 </p> 1030 1030 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2> 1031 <p id="rfc.section.6.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers.1032 A transparentproxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.1031 <p id="rfc.section.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent 1032 proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that. 1033 1033 </p> 1034 1034 <p id="rfc.section.6.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: … … 1155 1155 the origin server would return for a new request on that resource. 1156 1156 </p> 1157 <p id="rfc.section.11.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request1158 th at caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However,1159 several ruleshelp reduce the likelihood of erroneous behavior.1157 <p id="rfc.section.11.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused 1158 the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules 1159 help reduce the likelihood of erroneous behavior. 1160 1160 </p> 1161 1161 <p id="rfc.section.11.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from … … 1277 1277 </pre><p id="rfc.section.15.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When 1278 1278 such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest 1279 of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol1280 might applythese directives to header fields not defined in HTTP/1.1.1279 of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply 1280 these directives to header fields not defined in HTTP/1.1. 1281 1281 </p> 1282 1282 <p id="rfc.section.15.2.p.5">The cache-control directives can be broken down into these general categories: </p>
Note: See TracChangeset
for help on using the changeset viewer.