Re: First draft of a list of goals

In message <199512212354.XAA28495@wswiop05.win.tue.nl>, Koen Holtman writes:
>Jeffrey Mogul:
>>    
>>Probably I would define "valid" as
>>        What the origin server would provide if it received the
>>        request at approximately this instant.
>
>I don't see how this definition of "valid" would fit in a HTTP caching
>model.  How could a proxy cache ever serve a "valid" copy without
>contacting the origin server?

It could not. But it could return "invalid" copies. Perhaps valid
was a poorly chosen term. How about "original" or "fresh"?

>Under the current draft, if a server at time T generates a response on
>URI U which includes an Expires or Cache-control response header,
>
>- this does _not_ mean that the server guarantees that the response
>  it will serve for U will not change until some time T+X.
>
>- rather, it means that the server finds it _appropriate_ for clients
>  to give the response to a request for U at any time up to T+X.

Agreed. I'm sure that's what he meant.

>A web caching model must thus be built around the idea of an origin
>server _giving permission to caches_ to present an old response as
>something the origin server _would not mind saying now_.

Right. We just need to agree on the term to express this.

Something like: the origin server can state a lifetime
for a response.

>Use of the term `valid entity' may be misleading, as the
>`valid/invalid' distinction is also used when talking about RAM caches
>in computers, where a `valid cache line' _does_ always hold the latest
>memory contents.
>
>Defining the protocol in terms of `appropriate entities' might be
>better.

hmmm... how about the following terms, used to describe responses:

	original -- exactly what the origin server would say
	fresh -- within the lifetime granted by the origin
		server  (or the client, since a request could
		say "I'm happy with stuff less than 1 hour
		out of date").
	stale -- not fresh. Not authentic. Protocol violation.

Note that these describe responses, not entities.

Many of these mechanisms also assume a global clock.

I made an attempt to formalize these notions the other day.
I think it might add to this discussion. See:


"HTTP Caching Rules and Heuristics"
http://www.w3.org/team/WWW/Protocols/WD-http-cache.html

It has some possibly out-dated notions about Expires:,
but I like to think it crystalizes things.


Dan

Received on Friday, 22 December 1995 00:46:05 UTC