Re: Questions (errata?) about caching authenticated responses

One scenario where caching of autheniticated objects is useful would be
where there is a common, large object (say, a PDF file) which must be
authenticated. Instead of returning the PDF from the server upon each
request, it's more efficient to allow an intermediate proxy to cache the
object, but force it to validate it each time, with the response headers

  Cache-Control: public, max-age=0, must-revalidate

The catch here is that all downstream proxies must correctly evaluate this
header, or there will be problems. Therefore, this is only really useful in
a private network (I've deployed that solution before, to excellent effect),
or on a trusted content delivery network.

If you wanted to have user-specific copies cached, I suppose you could use
the Vary mechanism:

  Vary: Authorization

but not many caches support this kind of content negotiation (yet). This
would tend to blow out the cache size, and unless the same user accesses
these objects a lot, it's not very useful.

Cheers,



On Mon, Jul 24, 2000 at 07:30:09PM +0200, Joris Dobbelsteen wrote:
> Something that if you need to authenticate to the proxy, and the response is
> private (e.g. private cache-control setting and/or authentication) that the
> cached object is stored in the proxy cache, but only be accessable if you
> authenticate with the same name???? (Private caching done on a proxy
> server?)
> 
> Maybe that I'm getting it wrong...
> 
> 
> I know that proxies are primarily intend to lower internet bandwidth and
> provide security (kind of firewall)...
> 
> 
> 
> - Joris Dobbelsteen
> 
> 
> > -----Original Message-----
> > From: Mark Nottingham [mailto:mnot@mnot.net]
> > Sent: saturday 22 july 2000 21:28
> > To: Joris Dobbelsteen
> > Cc: WWW WG (E-mail)
> > Subject: Re: Questions (errata?) about caching authenticated responses
> >
> >
> >
> > I think the point here is that maximum 'security' is not
> > always the goal;
> > sometimes, all that's needed is trivial authentication (which
> > is all that
> > can really be expected in any case), and cacheability of the
> > objects due to
> >
> > Cheers,
> >
> >
> > On Sat, Jul 22, 2000 at 04:05:31PM +0200, Joris Dobbelsteen wrote:
> > > The best solution for maximum security whould be:
> > >
> > > Authenticated request
> > > =====================
> > > Shared-Cache
> > > Do NOT cache the response, because it requires uses to
> > authenticate, and may
> > > not be accessed by everyone.
> > >
> > > Private-Cache
> > > A private-cache is used by ONLY ONE PERSON. This cache may cache the
> > > response (depending on the cache-control header), because
> > it can only be
> > > accessed by one person.
> > >
> > >
> > >
> > > - Joris Dobbelsteen
> > >
> > >
> > > > -----Original Message-----
> > > > From: Duane Wessels [mailto:wessels@ircache.net]
> > > > Sent: donderdag 20 juli 2000 7:48
> > > > To: http-wg@cuckoo.hpl.hp.com
> > > > Subject: Questions (errata?) about caching authenticated responses
> > > >
> > > >
> > > > I've been reading RFCs 2616 and 2617 about caching authenticated
> > > > responses, and have possibly found some inconsistencies.
> > > >
> > > > #1.     The very last sentence of Sec 14.9.4 (under
> > proxy-revalidate)
> > > > 	says: ``...such authenticated responses also need the public
> > > > 	cache control directive in order to allow them to be cached at
> > > > 	all''
> > > >
> > > > 	Yet, Sec 14.8 lists three cache-control directives that allow a
> > > > 	shared cache to reuse an authenticatd response: s-maxage,
> > > > 	must-revalidate, and public.
> > > >
> > > > #2.	If must-revalidate alone is enough to allow an
> > authenticated
> > > > 	response to be cached, and if proxy-revalidate is the same
> > > > 	as must-revalidate for a shared cache, is proxy-revalidate
> > > > 	alone enough to allow an authenticated response to be cached?
> > > >
> > > > 	If so, should proxy-revalidate be listed in section 14.8?
> > > >
> > > > #3.	RFC 2617, Sec 3.2.2.5 says:
> > > >
> > > > 	    when a shared cache ... has received a request containing
> > > > 	    an Authorization header and a response from relaying that
> > > > 	    request, it MUST NOT return that response as a reply to any
> > > > 	    other request, unless one of two Cache-Control (see section
> > > > 	    14.9 of [RFC2616]) directives was present in the response.
> > > >
> > > > 	I believe this is referring to section 14.8, rather than 14.9,
> > > > 	and "two" is not the right number?
> > > >
> > > > Finally, Sec 14.8 doesn't mention if a non-shared cache
> > needs to treat
> > > > an authenticated response specially.  I assume that a non-shared
> > > > cache can store and reuse an authenticated response by default.
> > > > Should that be made explicit?
> > > >
> > > > Duane W.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Monday, 24 July 2000 11:28:39 UTC