Re: dont-revalidate Cache-Control header

Here's a sketch of what I think a spec might look like, modeled off the
stale-while-revalidate spec.

- I wasn't sure how specific we should get about the handling of browser
reload behavior.
- The static resource must stay "semantically" the same in this spec. This
allows for static resources that could change on a byte-by-byte basis --
for example if they are recompressed, etc.
- The main security risk I can think of here is defacement (there's also a
similar operational risk of accidentally returning a static document on the
root page of your domain). As I noted, I think a reasonable mitigation here
is to only apply the static semantics to sub-resources. Personally as a
site owner, I'd prefer that UAs always revalidate content that the user
directly navigates to.

Abstract

This document defines a Cache-Control extension formalizing of HTTP
resources with long expiration times where the URI of the resource is
changed when the content of the resource is changed.

1. Introduction

RFC7234 states "The goal of caching in HTTP/1.1 is to significantly improve
performance by reusing a prior response message to satisfy a current
request" Highly performant websites seek to maximize the efficiency of HTTP
caches by changing the URI of their resources every time the resource
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.

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.
It MUST NOT be used in combination with "no-cache", "no-store", or
"must-revalidate". The server MUST send a max-age directive and SHOULD use
a delta-age of at least 30 days.

A cache MUST treat a response with the static Cache-Control extension as
having the maximum allowable lifetime for that cache. The cache SHOULD NOT
attempt to revalidate the response. Operations that would normally cause
the cache to revalidate the resource SHOULD result in the reuse of the
cached response. The cache MAY make an unconditional request for the
resource in response for an end-to-end reload. A user agent SHOULD NOT
generate an end-to-end reload in response to prominent user-facing
functionality such as a reload button.

2.1 Example

A HTTP response might have the header:

Cache-Control: public,static,max-age=31536000

While normally this resource would only be considered cacheable for 1 year,
a cache may choose to store it for as long as it wished. If the page using
this resource was refreshed, the user agent would not revalidate the
response. If the server wishes to change the contents of the resource in a
semantically meaningful way, it would place the resource on new URI.

3.  Security Considerations

User agents already have the capability of caching resources for long
periods of time. The static header alters the behavior of the reload button
so that it no longer triggers revalidation. The static Cache-Control
extension is designed to be used for sub-resources where the user does not
see the URI of the request. If an attacker were to compromise a directly
used URI (say the root document of a domain) and serve a response with the
static extension, it could deface the URI in a way that would not easily be
reversed by the refreshing the page. User Agents MAY  ignore the static
extension when a URI is directly navigated to by a user rather than
referenced by another page.

On Thu, Jul 16, 2015 at 10:26 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> > On 14 Jul 2015, at 2:36 pm, Ben Maurer <ben.maurer@gmail.com> wrote:
> >
> > Static is a fairly reasonable name. Static does imply that the resource
> will *never* be revalidated (ever) vs the dont-reload which implies no
> revalidations prior to expiration. I don't have any preferences between the
> two but wanted to call that out.
> >
> > What's the next step here?
>
> Writing a small spec. Is there anyone who has experience doing this that's
> interested in helping out here? E.g., Ilya?
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>