Re: dont-revalidate Cache-Control header

On Fri, Jul 10, 2015 at 2:57 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> Questions:
>
> 1. MUST NOT seems too harsh. It'll put UAs that don't yet understand the
> directive as non-compliant. And we can't be sure whether there could be
> legitimate reasons for UAs to send conditional GET.
>

What about something like:

The UA MUST re-use the request in response to normal page loading or reload
requests discoverable by the average user. The UA SHOULD make
non-conditional requests when specifically requested via advanced browser
functionality (eg, developer tools, shift+refresh)

My ultimate goal here is to set very clear expectations for UAs in handling
this content.


> 2. If the user views a subresource, e.g. an embedded image, directly as a
> top resource, and the user refreshes UA, what should UA do? It's unlikely
> that UA will refuse to oblige the refresh request.
>

Yes, I think it would be very reasonable for UAs to only implement this on
subresources. This prevents a situation where a website accidentally sends
down a dont-revalidate page in response to GET / and then the user can
never recover from the error except for by clearing cache. If the
accidental header occurs on a subresource the website can simply change the
resource.

3. If UA requests an older version of a resource that the server no longer
> keeps, how should the server respond? If the server returns the latest
> version, it'll compromise the semantics of the URI. This requires clearer
> specification.
>

What do you mean by request an old version? If the browser requests
/X-v2.js but the current version os /X-v3.js, the server should respond to
/X-v2.js with v2 of the javascript. If the developer has deleted that
javascript, the server should return a 404. The developer should never
re-use the /X-v2.js URI for other content. They could choose to re-upload
/X-v2.js to the same URL in the future if they wanted to so long as it had
the same content.

Basically, if you have a URI /X-vY.js once you serve a dont-revalidate
response on that URI you must forever either (1) serve the same content (2)
serve an error.

That said, your content doesn't necessarily have to be byte-for-byte
identical, it just needs to be logically the same. For example, you might
have a CDN that gzip encodes the file. If two nodes on the CDN gziped the
file slightly differently that would be OK. The key is that you have
absolutely no expectation that browsers will ever re-fetch a
dont-revalidate URI once they have fetched it.

-b