W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1999

General confusion about Cache-Control headers

From: Nottingham, Mark (Australia) <mark_nottingham@exchange.au.ml.com>
Date: Fri, 21 May 1999 15:06:20 +1000
Message-ID: <D900F0C3D524D111971F00805F0D50E1022F4883@SV-MEEXCH-01.au.ml.com>
To: http-wg@cuckoo.hpl.hp.com
Just to bring it to people's attention, and perhaps stimulate some
discussion;

I've noticed in dealing with many cache implementors, on this list and in
documentation around the net (including my own) that there's a lot of
confusion about the exact meaning of the various Cache-Control HTTP headers.

Some of this may have been cause by differences between RFC2068 and the
Draft Standard (rev-06), but I think it is more to do with their names.

Particularly:

* must-revalidate (response header), according to rev-06, does not mean that
the client (whether browser or cache) must revalidate on every request; it
means that a client cannot take liberties with the object's freshness.
proxy-revalidate is similar, but only applies to shared caches.

* no-cache as a response header does not mean that the object cannot be
stored in a cache; rather, it means that it must be revalidated upon every
request. As a request header, it means that a cached copy cannot be used.
IMHO this is unfortunately named, because of the different meanings in
different contexts.

The latest place I've noticed this is the HTTP State Management
documentation.

Regards,



Mark Nottingham
Internet Project Manager
Merrill Lynch Australasia (Melbourne)
Received on Friday, 21 May 1999 06:08:04 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:31 EDT