Re: Koen's comments on http://ftp.digital.com/%7emogul/cachedraft.txt

    Opaque validators only improve on the use of Last-Modified times as
    validators in a small number of cases.  If the service author knows
    that the 1-second accuracy that the date provides is more than
    enough resolution, he should not be required to go through the
    trouble of generating a header with an opaque validator.

    This boils down to what Roy has been saying: if you want to require
    the service author to do extra work, there should be some extra
    benefit involved.

This is a similar misunderstanding as the one related to a cache's
choice of a Fresh-until value where none is specified.

Let me make it QUITE clear (since I have obviously failed to do so)
that I am not trying to make any extra work for service authors.
My expectation is that in almost all cases, the server implementor
will choose a simple and unmodifiable algorithm for generating
Cache-validator: values, and the service author (or system
administrator will never have to think about them).

Further, there is NO requirement in my proposal (NONE!) that the
opaque validator be any better (in any way) than a Last-Modified
value.  The HTTP server implementor could certainly choose to
use the last-modified date as the Cache-validator: value.  In
other words, it is perfectly legal for a response to include:
	Last-modified: Thu Jan  4 20:33:22 1996
	Cache-validator: "Thu Jan  4 20:33:22 1996"
(I'm even open to allowing whitespace in the validator, if people
insist).  Of course, if I were writing this server, I would
do everyone a favor by using a more concise encoding of the
last-modified date in the cache-validator.  For example:
	Last-modified: Thu Jan  4 20:33:22 1996
	Cache-validator: 80DC99B3
(8 hex digits can encode the full precision of an HTTP-date for
the next few decades).

So, to restate things as clearly as possible: NO SERVICE AUTHOR
NEED EVER CARE ABOUT THIS.

However: if any server/service authors DO want to use a different
technique to construct the opaque validator, my proposal gives
them the chance to do so.

    >what [should] a client
    >do if a server doesn't provide one?  (Revert to GET I-M-S?)
    
    Yes.

I'm comfortable with this, as long as it is made an absolutely
mandatory part of the specification that all HTTP/1.1 clients
and caches completely and properly implement the opaque-validator
mechanism.  That is, if the server does supply an opaque validator,
then the clients and caches MUST use it instead of a Last-modified
date (in order to claim compliance with HTTP/1.1).  If you'll agree
to this requirement, I'd be willing to make it optional for servers
to generate Cache-validator: headers.
 
As for your comments on my attempt to define "correct": I'll think
about them.  Meanwhile, feel free to suggest your own.

    >Good point about page counters.  And yet, it's quite clear that
    >the draft 1.1 specification allows caching of GET and HEAD methods
    >unless the server specifies otherwise.
    
    Yes.  It also clearly allows servers to produce side effects when
    processing a GET or HEAD.

We're arguing here about Roy meant to say, and without much closure.  Roy,
what DID you mean in section 14.2?

    >Is it OK if I change this
    >to be:
    >   Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
    >   specification [1] implies that GET and HEAD methods should not have
    >   any side effects that would prevent caching
    
    Side-effects never prevent caching, response headers do.
    
    > the results of these
    >   methods, unless the origin server explicitly prohibits caching.
    
    This would still mean that most page counters in use today are in
    violation of your interpretation, because these counters to not
    generally produce Expires headers.

I think you're splitting hairs, but perhaps this version will please
you:
	Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
	specification[1] implies that GET and HEAD methods should not
	have any side effects that would prevent caching the results of
	these methods, unless the origin server explicitly prohibits
	caching.  We make this explicit:  unless the server explicitly
	disables caching, GET and HEAD methods SHOULD NOT have side
	effects that would lead to erroneous behavior if their
	responses are taken from a cache.  They may still have side
	effects, but a cache is not required to consider such
	side effects in its caching decisions.  Caches are always
	expected to observe an origin server's explicit restrictions
	on caching.

-Jeff

Received on Wednesday, 10 January 1996 03:30:05 UTC