Updated issues lists

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