Re: ID for Immutable

hey amos - thanks for the thoughtful reply. Let's work through these and
I'll incorporate it into a -01

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

>
> This control seems like it will also be useful for proxy caches to
> prevent relaying the same revalidations from older clients that don't
> support the control.
>
> However the draft does not mention any proxy handling.
>
> * does it override must-revalidate etc on the stored response?
>  - what about proxy-revalidate?
>

my understanding is that must-revalidate and proxy-revalidate only apply to
stale responses. immutable only applies to fresh responses - therefore I
don't think it has any impact on *-revalidate handling.


>
> * does it override a client request max-age=0 and/or request no-cache?
>  - the stated intention implies that it does.
>
>
I think a request with no-cache means don't use the cache - so any
directives in the cache including immutable are irrelevant. (the draft
should say this about immutable). I wouldn't think requests bearing
no-cache are using revalidations anywhere along the chain - this is
normally the mechanism afaik used to correct corruption.

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.


> * assuming immutable overrides those client reload signals; is the proxy
> supposed to deliver a 200, 304 or 4xx to clients sending max-age=0 ?
>
>
I don't think immutable impacts that much. The proxy has used immutable to
auto-revalidate its stored response.. whether it returns that to the
user-agent as a 200 or 304 I would assume would depend on whether the
user-agent made a conditional request.


> * how does immutable interact with the 'must not send on re-use' headers?
>  - ie. no-cache="Set-Cookie", private="Set-Cookie" and similar cases ?
>

you're going to have to walk me through what you're thinking here because
I'm not immediately seeing the relevance. Immutable allows a client
(including a proxy) that is about to make a conditional request for a fresh
stored response to know that it is going to receive a 304 for that before
doing so and therefore avoid the transaction if it chooses to. Are you
suggesting that the resource varies by cookie or somesuch? I would think
that would be taken into account in the general logic of "do I have a fresh
resource for this request" logic.

wdyt?