Subject: Re: ID for Immutable

From: Leif Hedstrom <[email-masked]>
Date: Mon, 7 Nov 2016 14:20:25 -0700

> On Oct 26, 2016, at 3:02 PM, Patrick McManus <[email-masked]> wrote:
> 
> [as individual]
> 
> FYI
> 
> A new version of I-D, draft-mcmanus-immutable-00.txt
> has been successfully submitted by Patrick McManus and posted to the
> IETF repository.

Interesting. Couple of quick thoughts with my proxy-server hat on.

1) Many (most?) reverse proxy servers has features to ignore e.g. Cache-Control: max-age=0, or Cache-Control: no-cache from the clients. Not doing so would really open up some ugly rat holes for cache busting. [See the ATS configs below].

2) As such, this new CC: immutable directive seems geared primarily towards user-agents and possibly for forward proxies?

3) I didn’t read particularly carefully, but would it make sense to specify exactly what headers a proxy would ignore in favor of CC: immutable? I’m thinking in my case, we’d honor a CC: immutable over some of our configuration options [again see below].

For 3), I believe most clients will send something like 

	Cache-Control: no-cache
	Pragma: no-cache

correct when doing a “force” revalidate? I understand that this is UA specific, but if we are going to say something about this for intermediaries, maybe worth pointing this out? If so, what about Cache-Control: max-age=0?

Cheers,

— leif

P.s
Apache Traffic Server settings (defaults):

	CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
	CONFIG proxy.config.http.cache.ignore_client_cc_max_age INT 1

P.P.s
Yes, we know this violates the RFC :-).

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 8 Nov 2016 17:29:12 +1300

On 8/11/2016 10:20 a.m., Leif Hedstrom wrote:
> 
>> On Oct 26, 2016, at 3:02 PM, Patrick McManus wrote:
>>
>> [as individual]
>>
>> FYI
>>

It is also proving to be useful for the other types of proxy, to reduce
the need to explicitly configure overrides that abuse the normal HTTP
behaviour. Such as you mention below in your 'PS'.

> correct when doing a “force” revalidate? I understand that this is UA specific, but if we are going to say something about this for intermediaries, maybe worth pointing this out? If so, what about…

In previous posts of this thread we (Patrick, Martin, myself) have
concluded that immutable must not have any effect on no-cache from the
client.

It should only prevent backend revalidation of fresh content. Such as
that triggered by max-age=N (any N) or If-Modified-Since from the client.

Hopefully the next draft iteration will make all that a lot clearer.

> Yes, we know this violates the RFC :-).

AIUI, immutable should make the second one much less useful.

The first in my experience leads to more user complaints about broken
pages than its worth, but YMMV. In Squid we provide a control to convert
the no-cache into a revalidate request to the backend. That avoids the
cache busting aspect while still allowing data updates when reload is
actually needed.

Cheers
Amos