Re: weak validators (resend)

[Oops, I just noticed that the message about weak validators I just
sent had the wrong subject line, so I am resending it with the correct
subject line.  Sorry.]

Some observations after todays phone conference of the editorial
group:

On Last-Modified: It seems we agreed that the use of last-modified for
cache validation should be phased out.  Most people would not like
proxies to rely on the Last-Modified value when combining ranges,
because of the 1.0 servers around.  There did not seem to be much
support for Roy's idea to require that 1.1 servers make the
last-modified date a `strong' validator that is guaranteed to be
different for different entities, even if the entity bound to the
resource is updated twice in one second.

On terminology: we may need to introduce the concept of a `weak
validator' because we need to talk about last-modified being `weak' in
the 1.1 document.  If we need to, we have to invent a better term than
`weak validator'.

On weak opaque validators: it is clear that Roy thinks these are evil,
and must never be in HTTP.  Others do not want to discount the
possibility that weak validators could significantly improve future
HTTP performance for some future applications.

On weak opaque validators in 1.1: Jeff argues that, though he cannot
invent a `killer app' for them now, we should introduce weak
validators in 1.1 (even if they may never be generated by 1.1 origin
servers), because if we don't, we may not be able to introduce them
later, or only with great pain.

If this were not true, if we _could_ introduce them later painlessly,
then we could make weak opaque validators a `not in 1.1' issue.

What about this: if we leave weak opaque validators out of 1.1, we can
add them in 1.2, if we decide we need them, by adding a

 Cval-Not-For-Ranges = "Cval-Not-For-Ranges" ":" cval-info

header.  The `weak' cval-info values in such a header would just be
ignored by 1.1 caches relaying these responses, because these caches
ignore headers with unknown names.  As long as the response also
contains a Last-Modified header, no performance will be lost in these
1.1 caches.  If 1.2 clients include weak cval-info values from
Cval-Not-For-Ranges headers in If-Valid/If-Invalid headers of requests
sent through 1.1 caches, the 1.1 caches will not break: they will pass
the request on towards the origin server because the cached response
did not include a Cval header with a matching validator.

So adding weak opaque validators in 1.2 seems to be painless.

Could it really be this simple?  Or is there a hole in my reasoning
above?

Koen.

Received on Friday, 12 April 1996 00:20:04 UTC