Re: #403: cacheability of Authentication and no-cache

I've removed the caching-specific language from p7 and replaced it with a reference to p6.

Amos, I think we can close the issue now; please speak up if you have more information.

Cheers,


On 16/11/2012, at 9:23 AM, Mark Nottingham <mnot@mnot.net> wrote:

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

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

Received on Tuesday, 27 November 2012 03:15:38 UTC