W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1998

Cache-control and Authentication

From: Nottingham, Mark (Australia) <mark_nottingham@exchange.au.ml.com>
Date: Tue, 1 Sep 1998 19:18:35 +1000
Message-Id: <D900F0C3D524D111971F00805F0D50E1EED3D9@SV-MEEXCH-01.au.ml.com>
To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
I'm attempting to get my head around the newest draft of 1.1, and was
wondering if someone could clarify this for me:

Let's say a server has content that clients access through a 1.1-capable
cache (this is internal, so it can be controlled). There is a section of
the content that requires basic authentication, but the content does not
change based upon that authentication; any user-specific changes
controlled by the path, query and parameters.

What is the correct way to allow caches to keep, and satisfy requests
from, a local copy, while still forcing the request to be revalidated
(In this instance, so that the different users are indeed authenticated,
as well as maintaining freshness, which is critical in this
application)?

 From reading section 14.9 as well as Squid docs, I'm lead to believe
that this can be done by server response headers that include

Cache-control: no-cache Authorization

 From my reading, this should cause and IMS to be issued WITH the new
authentication header, which will enable the cache to serve the local
request IF the user is authenticated, and IF the object has not changed.
Is this correct? Or would this be situation be covered by 

Cache-control: public


Thanks,



Mark Nottingham
Internet Project Manager
Merrill Lynch - Melbourne, Australia
Received on Tuesday, 1 September 1998 02:24:21 EDT

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