W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Questions (errata?) about caching authenticated responses [#174]

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 24 Jul 2009 11:51:15 +1000
Cc: Duane Wessels <wessels@packet-pushers.com>
Message-Id: <4BECFD62-55E9-45D5-9CF0-3B18DF51C37F@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
My take:

On 25/06/2009, at 4:12 PM, Mark Nottingham wrote:

> Trolled up from the old list..
>  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/174
> Begin forwarded message:
>> Resent-From: http-wg@cuckoo.hpl.hp.com
>> From: Duane Wessels <wessels@ircache.net>
>> Date: 20 July 2000 3:47:59 PM
>> 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.

I can understand s-maxage making an authenticated response public (and  
if that's agreed, it needs to be added to p6 2.1).

However, I think that a shared cache storing an authenticated response  
because it has must-revalidate is going to be surprising and  
undesirable in almost any situation; "must-revalidate" means "don't  
serve this stale", not "shared caches can store this authenticated  

Does anyone know of a cache that implements this? Since there's a  
conflict in the specs here, I'd hope that implementations would be  
conservative. My inclination here is to remove must-revalidate from  
14.8 as a way of indicating that an authenticated response can be  

>> #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?

As per above, my preference would be not to. proxy-revalidate in an  
authenticated response that doesn't explicitly have a 'public'  
directive should be a no-op.

>> #3.	RFC 2617, Sec 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?

Seems like an errata for 2617.

>> 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?

I think this is made more explicit by p6 2.1, but if anyone wants to  
propose text...


Mark Nottingham     http://www.mnot.net/
Received on Friday, 24 July 2009 01:51:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC