Re: ID for Immutable

On Wed, Oct 26, 2016 at 10:23 PM, Amos Jeffries <squid3@treenet.co.nz>
wrote:

> On 27/10/2016 2:28 p.m., Patrick McManus wrote:
>
> > max-age=0 is messy, but I think OK, for a proxy cache to apply the
> > immutable logic to its stored fresh response. The alternative is really
> > just to revalidate it, but the meaning of immutable is that the
> > revalidation is going to return 304 during the freshness lifetime.
> >
> > You would need to make sure not to send a Age > 0 in the response.
> >
>
> Hmm. Does that mean we need to update the output Date header with the
> amount which would otherwise be in Age?
>
> Which makes me wonder if immutable needs to be forbidden on responses
> with heuristic freshness. The current wording does not differentiate
> between explicit and heuristic freshness.
>
> If we adjust the Date in the absence of a Last-Modified we could be
> wrongly extending the freshness period estimated by downstream caches.
>
>
I think you've gotten me to change my mind on Age > 0. I wrote that
concerned that a client unaware of immutable would get cranky at seeing
"Age: 30" in response to a request with "max-age: 0". But I don't really
have any evidence of that, nor upon reflection would I really expect anyone
to care as long as the Age was correct.

The alternative, as you point out, is messing with the end-to-end headers..
like Date. And that's definitely worse.

So I'll change my position and say the proxy should just send the cached
response in the way it normally would for a full cache hit. (which could be
a 200 or 304 depending on whether the request was conditional or not). does
that make more sense?


>
>
> >
> >
> >> * how does immutable interact with the 'must not send on re-use'
> headers?
> >>  - ie. no-cache="Set-Cookie", private="Set-Cookie" and similar cases ?
> >>
> >
> [...]
>
> The main use-case for those controls using lists of header names is to
> force a revalidate to get new values per-client for those headers.
> Set-Cookie being the one seen most often, though others are possible.
>
> At present we revalidate stored responses with these controls so the 304
> from the server can produce any relevant new values for the new client.
>
>
as I understand this, your choice to revalidate the stored responses is an
implementation decision (no doubt a wise one!).. the spec allows you to
reuse the fresh content directly with (e.g.) set-cookie redacted but your
experience tells you that the revalidation makes more sense.

I don't think immutable really addresses the concern one way or the other..
it says that the same representation will come back, but the response
headers might indeed be different just as they may be different on a 304 vs
200. If I were you I would keep doing the revalidation, but because you
aren't required to do so in the first place I'm not sure what the spec
would say about that.

and honestly, as noted in the specs, the qualified forms of no-cache and
private are often treated as unqualified forms.. so I wouldn't expect folks
to be declaring immutable content with them as it requires fresh cached
content to work. your trick to store it and revalidate it to pick up new
headers is clever and should just carry on :)