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

lör 2009-07-25 klockan 10:34 +1000 skrev Mark Nottingham:

> I had a quick look through the old caching list and didn't find  
> anything, but this list's predecessor had a few relevant bits:

a little confusing as some of that predates s-maxage.

unfortunately I could not find anything in that on why must-revalidate
should also imply public, but possibly it was already defined that way
by then...

but there is a clear spirit of trying to optimize cache-control by only
requiring a single directive "in common cases" (or what was assumed to
be "common case") without at the same time considering the effects on
non-common cases combined with several proposed directives
added/removed/modified at the time..

This over optimization can still be seen in the definition of s-maxage
implicitly also meaning proxy-revalidate. I guess it was believed no one
would want to ask shared caches to just TRY to revalidate more often
than private ones and at the same time allow for the shared caches to
respond with stale information if the revalidation wasn't possible for
one reason or another. Which partly seems to come from the view that the
only reason one would want shared caches to revalidate more often is
when there is authentication of some kind.. (to be exact that the only
s-maxage setting that is relevant to care about in context of
authenticated responses is s-maxage=0 and that it therefore should also
imply proxy-revalidate). Unfortunately nothing we can change now and we
will just have to live with it even if it rules out a whole family of
freshness settings.

Going back reading RFC2068 for a while... and there the picture is quite
different when it comes to proxy-revalidate in authenticated responses:

     1. If the response includes the "proxy-revalidate" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but a proxy cache MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.
     2. If the response includes the "must-revalidate" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but all caches MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.
     3. If the response includes the "public" Cache-Control directive, it
        may be returned in reply to any subsequent request.

So it turns out that what have happened with respect to proxy-revalidate
is that the MAY rule regarding proxy-revalidate was lost from this
section when s-maxage was added in RFC2616. Probably an editorial error
when introducing s-maxage, alternatively (but less likely) there may
have been discussions to remove proxy-revalidate entirely as the
definition of s-maxage makes proxy-revalidate redundant, but then this
text was never added back when it was decided to keep proxy-revalidate.

Proposed resolution to the proxy-revalidate issue: Simply add back the
text from 1. above where it was nly correcting the text to say "shared
cache" where it said "proxy", at least for now. This makes
specifications consistent with what was specified in RFC2068 and what
one would expect from "use as few cache-control verbs as needed".

Regarding must-revalidate it may well be the case that this should be
restricted to say "non-shared caches" instead of "the cache" for the
reason outlined before, but if in doubt one can always use
private/public to specify what you intended so it's not that critical.
It's been specified like this "for ever".

Hmm.. on a second reading I notice "private" is missing in this section.
A shared cache MUST NOT use a response with "private", especially not
when there is authentication involved... Current text kind of implies a
shared cache is allowed to cache those as long as it always revalidates
on every request IF the request was authenticated but not otherwise..
which is nonsense. (with it being nonsense I surely hope noone have
implemented their shared caches in such manner..)

Regards
Henrik

Received on Saturday, 25 July 2009 16:07:23 UTC