W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: Ordered 'opqque' validators

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 05 Feb 96 19:38:03 PST
Message-Id: <9602060338.AA10430@acetes.pa.dec.com>
To: Shel Kaphan <sjk@amazon.com>
Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
    What is at issue is the semantics of conditional GET.  Do
    conditional GETs always have to be forwarded all the way to the
    origin server in all cases, even if a cache contains a fresh
    response with a matching validator?

No.  If the cache is sure that its own copy is fresh, then it can
return it to the requesting client.

    I suppose it doesn't make sense for validating GETs to be
    answerable by a cache, since the requestor must already have a copy
    of the object (else why would it have the validator?), and so, if
    it believes the document to be fresh, why would it be validating it
    unless it really wanted to check with the origin server?

You've somehow gotten extremely confused.  "Fresh" values do not need
to be validated; the server (by attaching an Expires: date in the future)
has indicated that the response is usable without validation for the
indicated period.

Conditional GETs are done by a client or cache that has a copy
of the resource, and a validator (either an opaque one or a last-modified
date) for the resource, and if the client or cache believes that
its copy is stale.

My draft proposal includes
	Cache-control: reload
	Cache-control: revalidate
to allow a client to force a cache to reload or revalidate a
resource that it (the cache) would otherwise return without
checking.  But this should only be necessary when something has
gone wrong (such as an incorrectly assigned Expires: date or
a corrupted date).

    You are talking above about a different scenario than what we were
    considering.  We were talking about a situation in which a cache
    contains a single "best" response so far, and is presented by a
    client with a validator that does not correspond to the entry
    already in the cache.  In this case, although the entry in the
    cache may still be fresh and may in fact be the "current version",
    without additional state the cache cannot respond to a conditional
    request using the fresh entry.

Nonsense.  If the cache believes its own copy is fresh, then it
can return it to the client.  If the client's validator is the
same as the cache's validator, it should return "304 Not Modified"
but otherwise it must return the entire entity.

The only difficult case arises when a client (or cache) is getting
copies of the same resource from two different paths to the origin
server.  E.g., suppose that my browser is somehow able to use both
of these proxies:


Suppose that I round-robin between the proxies, and I keep
retrieving http://www.digital.com.  So I do this sequence:

	GET http://www.digital.com
		from proxy1
					proxy1 GETs from www.digital.com
						Validator = XX1
[at this point, someone at the server modifies the file]

	conditional GET http://www.digital.com
		from proxyB
	If-Valid: XX1
					proxyB GETs from www.digital.com
						Validator = XX2
	conditional GET http://www.digital.com
		from proxy1
	If-Valid: XX2

What should proxy1 do?  Well, it depends on whether the copy it
has is still fresh.  If the server assigned an over-optimistic
Expires: date, then it is still technically fresh and proxy1 can
hand it back to the client, even though this would appear somewhat
paradoxical at the client (hence the need to set honest Expires:

One could argue that this problem would go away if we simply used
If-Modified-Since: or some other totally ordered validator, but I
believe that the scenario here depends upon inconsistent treatment of
Expires: dates (why would the client have done the second GET unless it
thought the value it got from proxy1 was already stale? in which case
proxy1 would only return it in response to the third GET if there is a
serious clock-skew problem).  So if we keep the clock skews under
relatively good control (i.e., by using NTP and the Age:  header), I
don't think this case is likely to happen.

Received on Tuesday, 6 February 1996 03:47:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC