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

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?


>
> While we're here -- I'd like to remove all of the caching information from p7 and replace it with a reference to p6 3.2. Make sense?

Yes.

>
> On 14/10/2012, at 2:36 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
>> While reviewing the clauses for cacheability I find an undefined case which can reasonably be expected to appear in real-world traffic.
>>
>> Comparing p6 section 7.2.2.3 and 7.2.2.5 it is clear that response Cache-Control "no-cache" with no values is semantically equivalent to "must-revalidate, max-age=0".
>>
>> p7 section 4.1 clause 2 states that responses with "must-revalidate" MAY be cached for use on later requests provided revalidation is done.
>>
>> Assuming that p7 clause is true, I see no reason why "no-cache" response control cannot be also added to p7 section 4.1 list of exceptions along with must-revalidate.
>>
>> Amos
>>
>>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

Received on Thursday, 15 November 2012 10:59:11 UTC