Subject: Questions (errata?) about caching authenticated responses

From: Duane Wessels <[email-masked]>
Date: Wed, 19 Jul 2000 23:47:59 -0600

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.

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Sat, 22 Jul 2000 16:05:31 +0200

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:[email-masked]]
> Sent: donderdag 20 juli 2000 7:48
> To: [email-masked]
> Subject: Questions (errata?) about caching authenticated responses
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Jul 2000 12:28:13 -0700

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,

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

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Mon, 24 Jul 2000 19:30:09 +0200

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

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: saturday 22 july 2000 21:28
> To: Joris Dobbelsteen
> Cc: WWW WG (E-mail)
> Subject: Re: Questions (errata?) about caching authenticated responses
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Jul 2000 11:24:46 -0700

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,

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