Re: ID for Immutable

On 27/10/2016 2:28 p.m., Patrick McManus wrote:
> 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 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.
> 

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.


> 
>> * 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.

Okay.

> 
> 
>> * 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?
> 

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.

Going with the style of immutable meaning as implicit 304 from upstream
we could just drop the headers as if it had produced none. But that is
quite a gotcha situation any applications using immutable will need to
be warned about clearly.

Amos

Received on Thursday, 27 October 2016 02:23:59 UTC