Re: dont-revalidate Cache-Control header

Thanks for the feedback!

On Thu, Jul 16, 2015 at 1:35 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> > changes then giving each such URI an extremely distant expiration date.
> >
> > The static HTTP Cache-Control extension clarifies that a resource is
> > guaranteed never to change and allows caches to optimize based on these
> > semantics. For example, it allows user agents to avoid revalidating
> static
> > resources when a user presses the reload button. It also signals to
> caches
> > that the expiration date of the object may be set further in the future
> > than the actual expected lifetime of the object.
>
> I dont think that last statement is correct. "may be set" implies that
> heuristic lifetimes are applicable. But this control is explicitly
> setting maximum lifetime when Expires/max-age/s-maxage are absent. That
> is not a heuristic estimation but the absolute "infinity" value for the
> cache.


What I was trying to say here is that if I have a resource foo-v1.js with a
lifetime of 1 year, I'm not actually expecting the resource to be useful
for 1 year, merely that the value of the resource won't change. "static"
might help signal this and change cache ranking algorithms.

That said, this was a side note, and I don't know of anybody who uses
expiration dates in this way, and could probably be deleted.



> >
> > 2. The static Cache-Control extension
> >
> > When present in an HTTP response, the static Cache-Control extension
> > indicates that the semantic content of the response will never change in
> > the future. A server MUST NOT either in the past or future serve
> different
> > semantic content for the same URI. If a server accidentally serves
> > different content on the URI, it MUST alter all resources that reference
> > that URI to reference a different URI. A server MAY either in the past or
> > future serve an error response for the URI. The static cache-control
> header
> > MUST be used with either the "public" or "private" cache-control
> directive.
>
> Why? content is always either public or private no matter what
> Cache-Controls are used.


Yeah, this may be better removed.


>
> > It MUST NOT be used in combination with "no-cache", "no-store", or
> > "must-revalidate".
>
> Or proxy-revalidate, or stale-while-revalidate, ... and the as yet
> undefined ones?
>
> Also, what if it does happen? Effectively any combination of cache
> controls can be sent.
>
> IMHO its probably best to say that when this control is present in
> responses any other controls causing revalidation MUST NOT be generated
> by senders, and recipients must ignore such revalidation controls. With
> the list of named controls just an example set.
>

Personally, I'd prefer to have static overridden by by other headers --
better to be more conservative and and make the browser refresh more.



>
>
> > The server MUST send a max-age directive and SHOULD use
> > a delta-age of at least 30 days.
>
> Why the MUST? "static" by itself could mean caching for maximum lifetime
> permitted. (ie ~68 years).
>
> The SHOULD and delta-age seems arbitrary. I thought the intent of
> "static" was to prevent heuristic cache expiry/revalidation limits being
> applied anyways.
>

I guess it doesn't need to be a must, but it seems like a poor decision for
one to have a short lifetime that would apply to UAs that did not implement
this extension. Maybe it should be "SHOULD specify a long max-age (eg, 30
days or more) for the sake of caches that have not implemented this
extension".



>
> >
> > A cache MUST treat a response with the static Cache-Control extension as
> > having the maximum allowable lifetime for that cache.
>
> There you go. :-) the max-age bit conflicts here.


The idea is that static should take precedence over max-age. You need to
support max-age for legacy caches. I could have been more clear here.




> > The cache SHOULD NOT
> > attempt to revalidate the response.
>
> s/SHOULD NOT/MUST NOT/ and this one line encompasses almost all the
> requirements about revalidation controls.
>

I debated about making this MUST NOT. Using MUST NOT would conflict with
any type of heuristics (in the security considerations section)

 s/by the refreshing/ by reloading/
>
> > extension when a URI is directly navigated to by a user rather than
> > referenced by another page.
>
> Lots of MUST criteria, then a giant loophole of MAY ignore it all is a
> bit rough. All the non-browser agents including middleware/shared caches
> either cannot identify a "directly navigated" URL (or consider
> *everything* as directly navigated) anyways so the MAY is just setting
> up a worse problem of conflicting cache behaviour between software.
>
> Probably best to leave the client sent Cache-Control:max-age=0 (aka
> force-reload) control operational as a non-conditional fetch. This is
> already implied by the text at the end of section 2.
>

You're right that I hadn't been thinking about this with the perspective of
browser with an intermediate cache. I guess the behavior I'm suggesting
here is that a browser should treat a refresh on the main resource the same
as it does today (send a max-age=0 request), however it should *not* do
this for sub-resources that have the static extension. Open to other
suggestions about behavior here -- mainly I want to provide a safety net if
a hack/mistake were to make www.foo.com/ return a corrupt document with a
static caching flag.