- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 16 Nov 2012 09:23:05 +1100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 15/11/2012, at 9:58 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 15/11/2012 6:50 p.m., Mark Nottingham wrote: >> Hi Amos, >> >> I've created that as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/403>. >> >> My .02 -- I seem to remember some discussion about this. While it's true that revalidation is necessary to make an authenticated, cached response work properly, it doesn't follow that every condition that would lead to mandatory revalidation is a signal from the origin server that it's OK to cache the response to an authenticated request. "no-cache" is a particularly poor example of such a signal, since it's often misunderstood. >> >> IIRC this is why we left no-cache out. > > I'm not quite sure I follow that. You left no-cache out of the list because it would be hard to explain rather than its semantics were wrong for the job? > Or can anyone point me at a use case where no-cache would cause the wrong behaviour when storing an authenticated response? It's easy enough to explain; we'd just add it to the list. The issue IIRC is that the other directives have always been an explicit signal from the origin that it's OK to store an authenticated response; no-cache has never explicitly been that signal, even though its behaviour may be similar. Changing that signal retroactively may have surprising effects for some who didn't intend it to be interpreted that way. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 15 November 2012 22:23:31 UTC