Re: Object revalidation / Cache-Control

Nottingham, Mark (Australia) wrote:

> I know this is splitting hairs, but I have a specific application in mind.
> If someone has implemented validation on an object with a query string, and
> the server advertises itself as 1.0, they lose unless they specify
> expiration. Ah, well, it's a matter for the WG, perhaps. At least they don't
> say anything about /cgi-bin/.

We are selecting to ignore the last part (restriction on HTTP 1.0).

> In practical terms, IMHO a cache shouldn't just mark all queries uncacheable
> willy-nilly; it discourages people from working to make them cacheable. I
> was very heartened to see that change in Squid 2.

No, and that is not something we are planning on doing either. Only to
have a recommendation that people should not tune their refresh pattern
to cause queries to have a "default-min-age" other than 0.

> > The *_VALIDATE options requires the object to be revalidated by them
> > selves alone. It is wrong have these inside the maxage/expires check.
>
> See previous thread about the meaning of *-revalidate. IMHO it does belong
> here.

Of course you are right again, at least partially ;-) I am only tired.

*-revalidate are revalidation control not cachability/staleness options.
If any of them are set and the object is stale then the proxy cache
needs to revalidate the object or fail if not possible. A proxy is not
allowed to override object staleness when *-revalidate is set, not even
if revalidation fails.

However, a proxy is allowed to use any heuristics in selecting freshness
lifetime when there is no explicit expiry time is available. This
heuristics may include Last-Modified or other less explicit inputs like
behaviour observed in the past.

> If it doesn't have a validator, and it doesn't have any age hints, how can
> you? Matching a regex against the URL isn't going to catch all of the truely
> dynamic ones, and users getting incoherent results will IMHO cause a lot of
> trouble and bad press for caching.

By using common sense when defining the rules (yes I do know that not
all people have what one would call common sense, but there are some who
do know what they are doing).

Dynamic pages should default to be uncachable, but some cache operators
have need to selectively override this on application per application
(or page) basis that are known to be cachable without trouble. Not every
cache admin has the will to convince site operators that caching is good
for all.

> I'm very heartened by http://www.alltheweb.com/ - it's very cacheable.
> (their results don't do validation, but they do have Expires:)

Defining cachability of a dynamic application is troublesome at best,
and to some extent a political issue. Who should have control of the
level of staleness a given set of users perceive of a site? But let's
try to stay away from politics here.

> As long as that information isn't used to determine whether the object
> should be cached as well -- this is what NetCache does (or at least did),
> and it caused no end of problems. We couldn't give the cache a stale object
> that was capable of being validated.

Only in the sense that a object which is considered to be stale from the
beginning and which does not have a validator (currently Last-Modified,
maybe also ETag and cousins in the future) should not be cached.
Received on Tue Jul 29 2003 - 13:15:58 MDT