Re: Questions (errata?) about caching authenticated responses [#174]

fre 2009-07-24 klockan 11:51 +1000 skrev Mark Nottingham:

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

We (Squid) always require public for authenticated responses. Perhaps
not optimal, but very easy to explain. If there is authentication
respond with public on resources not actually requiring authentication
if you want them cached.

But I can see the point about s-maxage implicit making the response
public even if not explicit stated in the cache-control header.

And given the fact that we do have the "private" cache-control I can
understand why must-revalidate also may implying public. But see below
for why not.

In HTTP/1.0 we did not have any of these, so any authenticated response
without Cache-Control has to be handled as private from the HTTP/1.0
legacy.

When Cache-Control was added both "private" and "public" was added at
the same time (or at least I think so, my history of Cache-Control only
goes as far as RFC2068), enabling servers to clearly express their
intentions whenever there is any doubt. And with HTTP authentication
being optimistic in that clients send the credentials without really
knowning it's needed and servers having a lot of content which does not
require authentication and where therefore authentication quite likely
isn't considered when selecting the proper cache-control settings it
makes some sense that some/many/all Cache-Control directives implicit
makes content public unless private is used. The question there is why
is the text restricted to s-maxage and must-revalidate, why not max-age
or proxy-revalidate or even no-cache for that matter as no-chache is not
much different from max-age=0, must-revalidate or even the mere presence
of a Cache-Control response header.

However, the definition of must-revalidate only speaks about this
directive forcing validation after an object has become stale, not that
it would also enable otherwise private (authenticated) objects to be
cached in a shared cache. As far as I know the Cache-Control definitions
nowhere speak about any other headers than public as the method for
marking authenticated content public. For example the definition of
must-revalidate says nothing about this, just a lot of further
restrictions compared to not having must-revalidate. This places authors
that want to tune their clients private caches in a somewhat bad
situation as they clearly run the risk of doing the wrong thing unless
they also happen to read the cache section and pay careful attention to
the notion of shared caches and that some cache-control headers may have
unexpected effects on authenticated content in such caches, almost
opposite to the effect the same directives have in the context on the
browser private cache.

Making that decision on must-revalidate just feels odd to me as it's not
what must-revalidate is about. In all other aspects must-revalidate
places further restrictions on the cache (shared & private), not
enabling.

So I am going to stick to the current implementation, and require public
for accepting authenticated content as cacheable.

I may change my mind if it can be shown that nearly all authenticated
content with Cache-Control also includes private in the set of controls,
but that's something which I am not in a good position to determine, not
is it something I would like my users to discover by trial and error..

Maybe we may change the implementation regarding s-maxage to implicit
assume public when s-maxage is used as this is an explicit instruction
for a shared cache which does not make sense to see on private content.
But it then begs the question if proxy-revalidate also means public,
which it probably should do by the same reasoning.

Perhaps the intention actually was to use proxy-revalidate in that text
and not must-revalidate. If proxy-revalidate is substituted in that text
then it becomes coherent and makes some sense. But I do not know if that
was the intention as I was not around in the discussions then. I
probably could have been but were not as I was not familiar with the
workings of IETF then.

Regards
Henrik

Received on Friday, 24 July 2009 23:19:47 UTC