- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 21 Feb 96 16:28:37 PST
- To: http-caching@pa.dec.com
- Cc: masinster@parc.xerox.com
Based on Koen's comments on my message yesterday, I've made a few updates to the list of Agreed and Not Agreed issues for HTTP caching. This is the final update that I'll be able to issue before the IETF meeting. -Jeff ---------------------------------------------------------------- "Agreed" Expires: and Cache-control: max-age=NNN (1) Origin servers may send either or both of Expires: and Cache-control: max-age=N on responses (2) If both are sent, an HTTP/1.1 implementation SHOULD obey the Cache-control: max-age=N directive, and so SHOULD ignore the Expires field value. (2b) but HTTP/1.0 implementations will ignore it, so servers SHOULD NOT depend on a cache obeying that directive. The behavior of max-age in a response should be equivalent to what would occur if this response had an Expires: field specifying the same number of seconds since its Date: field, but max-age overrides an explicit Expires: value. Expiration semantics A cache may keep an entry past its expiration time, but MUST NOT provide this value as a response unless it has been revalidated with the origin server. A user or cache administrator may override that "MUST NOT" with an explicit request, and if the resulting known-stale response is explicitly flagged to the user as being stale. Age calculations: There will be an Age: header. In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. The latter can be reliably calculated as Expires: - Date:, or from Cache-control: max-age=NNN (which takes priority). An entry's age can be calculated in two independent ways: now - Date: if the clocks are reasonably well synchronized Sum of "time resident in cache" for all caches involved, using the Age: header if all of the caches support Age: Given that we have two independent ways to compute the age, we can combine these as age = max(now - Date:, Age:) and as long as we have either synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result. The purpose of the Age: header is to pass this value along to the next recipient cache. Note that this correction can be applied at each HTTP/1.1 cache along the path, so that if there is an HTTP/1.0 cache in the path, the correct age is computed as long as the receiving cache's clock is in sync. We don't need end-to-end clock synchronization (although it is good to have), and there is no explicit clock synchronization step. "Cache-control: private" vs. "Cache-control: no-cache" (1) "Cache-control: private" remains as in Roy's draft, but with a mention of extensibility explicitly included. Single-user-agent caches are effectively allowed to ignore this directive. (2) "Cache-control: no-cache" is defined to mean exactly the same thing as "Cache-control: private", but with no exception for user-agent caches. (3) We add "Cache-control: no-store", which applies to the entire message and may be sent either in a response or in a request. If sent in a request, it means "do not store any part of either this request or any response to it." If sent in a response, it means "do not store any part of either this response or the request that elicited it." This applies to both single-user and shared caches. Caches should obey it but we explicitly caution against depending on it as a privacy mechanism. Users may explicitly store such responses outside of the caching system (e.g., with a "Save as" dialog. History buffers may store such responses as part of their normal operation. Cache-control: stale-max=NNN, fresh-min=NNN or something similar Necessary for user-centric control over freshness parameters. Cache-control: public Overrides restrictions on caching responses to requests with Authorization: headers Warnings: We will add a "Warning:" header to the HTTP/1.1 protocol, allowing a server (origin or cache) to provide machine-readable and human-readable information to supplement the HTTP status code. Ranges: Ari Luotonen will submit a revised proposal, describing the interactions between Range: and validation headers (If-Valid, If-Invalid, If-Modified-Since). Location: and spoofing We agree that the spec should prevent this Hit metering: We will include a simple and optional hit-counting mechanism. History buffers: The spec will make a clear distinction between these and caches Vary: Some sort of Vary: response header will be included. ---------------------------------------------------------------- "Not Agreed" (1) Transparency vs. performance: basic philosophy (2) Shall Opaque validators (If-invalid/If-valid) and If-modified-since: be the only cache-validation conditions? (3) Use of Content-ID for validation and variant identification: yes or no (4) Vary: proposal (5) Variant-IDs: yes or no (6) Do we need HTTP protocol elements to control history buffers? (7) When neither the Expires: header nor Cache-control: max-age is sent, should the rules determining what assumptions a cache can make about the expiration date depend on whether the origin server is HTTP/1.0 or HTTP/1.1? (8) Volume validation: yes or no (9) Caching and POSTs (10) Caching and PUTs (11) Can we do anything to help support bypassing? (12) names for certain Cache-control directives. Particularly, should we be using the same name on both requests and responses?
Received on Thursday, 22 February 1996 00:47:07 UTC