#403: cacheability of Authentication and no-cache

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.

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?


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 05:50:44 UTC