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

[Mark Nottingham <[e-mail]>]

Picking this issue back up and CC:ing Jeff for his recollections (see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/174> for background).

On 26/07/2009, at 2:06 AM, Henrik Nordstrom wrote:

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

Here's what I think happened. RFC2068 included this text in 13.2.1:

> If an origin server wishes to force any HTTP/1.1 cache, no matter how
> it is configured, to validate every request, it should use the
> "must-revalidate" Cache-Control directive (see section 14.9).


even though 14.9 of the same document says:

> When the must-revalidate directive is
> present in a response received by a cache, that cache MUST NOT use
> the entry after it becomes stale to respond to a subsequent request
> without first revalidating it with the origin server.


The former text mis-defining must-revalidate was removed from 2616, but not before it confused the authors of the Auth and Cookie specs, as noted in <http://tools.ietf.org/html/draft-mogul-http-revalidate-00>.


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

There was a conscious decision in 2616 to remove the effects of the misinterpretation of must-revalidate from the spec, including in the Authorization header.   Moving back to the 2068 text would cause yet more confusion.

Additionally, 2616 explicitly says in the definition of proxy-revalidate:

> Note that such authenticated responses also need the public cache
> control directive in order to allow them to be cached at all.


Counter-proposal:

Add a new section to p6:

---8<---
Shared Caching of Authenticated Responses

Shared caches MUST NOT use a cached response to a request with an Authorization [ref] header to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.

In this specification, the following Cache-Control response directives [ref] have such an effect: must-revalidate, public, s-maxage.

Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale [ref] by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server. 
--->8---

... with appropriate changes to p6 2.1, 2.2, as well as the definitions of the Auth header and appropriate CC directives.


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

Non-shared caches aren't affected by the Authentication header.


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


Are you referring to 2068 text or HTTPbis text here?

Cheers,

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