- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 24 Jul 2009 11:51:15 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Duane Wessels <wessels@packet-pushers.com>
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 content". 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 stored. >> #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 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? 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... Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 24 July 2009 01:51:54 UTC