where we stand on caching

You all probably noticed a lot of activity today.  Partly that was
because Roy is trying to catch up on his mail.  Partly it's because I'm
trying to catch up on my mail, and more specifically because about 24
hours from now I'll be disconnecting myself from civilization (no
phone, and certainly no computer) for a vacation until March 3.

Anyone who wants to beat me up about something had better do it in the
next 20 hours or so.  Anyone who wants to wait until I'm gone so that I
won't have a chance to defend myself ... if you really want to, that's
fine with me.

Anyone who wants to get off this mailing list better send mail to
http-caching-request@pa.dec.com ASAP.

Larry has asked me to try to come up with a list of things we agree on,
and a list of things we don't agree on.  That's what this message is
about, to the best of my ability.  Please don't quibble about minor
details; the point of this is to help guide Larry to decide what needs
to be discussed at the LA IETF meeting, and it would be sad to waste
that time arguing about stuff that has no real importance.

Anyway, what follows are two rather terse lists.  The first is "stuff
we agree on" and the second is "stuff we disagree on or haven't really
tackled yet."  I'm sure I have left stuff off of both lists, and
perhaps I've put something on the "agree" list that doesn't deserve to
be there.

The "disagree" list is rank-ordered (my crude ranking) solely to
provide some guidance to Larry about scheduling.

-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
	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
----------------------------------------------------------------

"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?

Received on Wednesday, 21 February 1996 03:40:51 UTC