Re: Cache-Control: no-cache

Nottingham, Mark (Australia) wrote:

> no-cache
> If the no-cache directive does not specify a field-name, then a cache MUST
> NOT use the response to satisfy a subsequent request without successful
> revalidation with the origin server. This allows an origin server to

Darn, they seem to have quite a bit of changes since I last read this
part of HTTP/1.1 specifications, and this without even including the
change in the changes section (this is a unquestionable semantics change
from RFC2068 where no-cache is "response message MUST NOT be cached
anywhere").

There are way too many Cache-Control directives in HTTP/1.1 draft6, but
if you compare it with RFC2068 I think it is clear what is going on.

RFC2068 defined a number of boolean attributes for controlling caching.

In HTTP/1.1 draft 6, it seems like they are attempting to replace these
boolean attributes with age based controls instead, where a age of 0 is
"must revalidate" at the level the control applies to. The boolean
attributes are kept, but has in at least one case (no-cache) changed
semantics to a more cache friendly attitude..

Needed changes to Squid Cache-Control directives:

* no-store, implement. what no-cache previously was I guess.
* no-cache, change from "don't cache" to "must revalidate".
* must-revalidate, cached object MUST NOT be returned if validation
fails.
* s-maxage, implement. Same as max-age (is max-age implemented properly
in HTTP replies?)

There is a slight difference in no-cache and max-age=0, in that objects
tagged with no-cache or must-revalidate MUST NOT be sent to clients
without sucessful revalidation, while max-age MAY be overridden by
configuration or revalidation failures.

The HTTP/1.1 draft 6 standard contains a great deal of information, but
is in part badly structured. There are many overlapping areas which are
somewhat inconsistent, and it is not easy to keep track of the order of
precendence of all MUST or MAY criterias chaining on each other from the
different areas which makes reading the standard quite hard.

One good example of this "overlapping sections" is when a previously
cached object may be returned to a client in event of a revalidation
failure. 13.8 says that a object MAY be returned unless it includes
must-revalidate, there are however several other MUST requirements that
requires a sucessfull revalidation in other sections and these override
section 13.8 (MUST has a higher priority than MAY).

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT