Subject: Call for Adoption -- Cache-Control: immutable

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2016 15:03:31 +1100

As discussed in Seoul, there seems to be strong interest in adopting Patrick's draft:
  https://tools.ietf.org/html/draft-mcmanus-immutable

Please indicate any concerns on-list; statements of support would also be helpful.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Dec 2016 04:55:45 +0000

I'm generally favorable toward this idea, but will note one open question in my mind:  This seems to be very tightly tied to the scenario of hitting refresh on a page whose content frequently changes but whose dependent resources don't.  Putting "immutable" on those dependent resources helps reduce the server load and time taken when the user hits refresh, either in their own local cache or in proxies that are on path to the site.

There seems to be a parallel discussion (see https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1vwx8WiUASKyC2I-2Dj2smNhaJaQQhcWREh7PC3HiIAQCo_edit&d=DgMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=1l7nWo9Y5pZ_Fce4oaurZQ&m=AlkS3R79U-PYonxL1dpzJx-7U842dQ1ecXQodjpgPSo&s=IRSkaXwsZPN79a5lIo4n-SJrwvSNDe2QQF3XichUZXo&e= for Chrome's) about softening the behavior of the refresh button to avoid force-refreshing all dependencies, which would likely have the same results.  Can someone point me to a scenario in which both are worth doing, or is this really a pair of mutually-sufficient solutions to the same problem?

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Wednesday, December 7, 2016 8:04 PM
To: HTTP Working Group <[email-masked]>
Cc: Patrick McManus <[email-masked]>
Subject: Call for Adoption -- Cache-Control: immutable

Regards,

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 8 Dec 2016 14:19:34 +0900

> There seems to be a parallel discussion (see https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1vwx8WiUASKyC2I-2Dj2smNhaJaQQhcWREh7PC3HiIAQCo_edit&d=DgMFAg&c=5VD0RTtNl…

There's a big difference between what is ideal (or close to ideal) for 
development and for production,...

For development, you want the "always reload everything" behavior. For 
production, you hopefully don't need that anymore. So the browser-side 
solution with a switch between "really reload everything" and "reload, 
but with moderation" could work. I think that at some time, Ctrl-R did 
the later, and Ctrl-Shift-R did the former on some browsers.

There are other tricks you can play. Some frameworks (e.g. Rails) add a 
number for a "stable" resource and increase the number every time that 
resource is changed.

Overall, it's probably possible to imagine an ideal world where only one 
such mechanism is used, but because neither browsers nor servers (and 
the stuff served by them) are perfect, we usually end up with needing 
more than one mechanism.

Regards,   Martin.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Dec 2016 20:27:46 +0000

Shift-Reload is different still -- all requests go out without looking at the cache in the first place.  So you see unconditional requests, rather than revalidations, and always get fresh content.  If those responses are cacheable, they still get added to the cache later, though.

The one situation I've thought of is that a change to browser behavior only gets the updated clients, whereas "immutable" supported in a proxy can effectively help every client behind them, updated or not.  However since immutable restricts itself to HTTPS, which is less likely to be proxied, how *much* larger is a very open question.

-----Original Message-----
From: Martin J. Dürst [mailto:[email-masked]] 
Sent: Wednesday, December 7, 2016 9:20 PM
To: Mike Bishop <[email-masked]>; Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>
Cc: Patrick McManus <[email-masked]>
Subject: Re: Call for Adoption -- Cache-Control: immutable

> There seems to be a parallel discussion (see https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1vwx8WiUASKyC2I-2Dj2smNhaJaQQhcWREh7PC3HiIAQCo_edit&d=DgMFAg&c=5VD0RTtNl…

There's a big difference between what is ideal (or close to ideal) for development and for production,...

For development, you want the "always reload everything" behavior. For production, you hopefully don't need that anymore. So the browser-side solution with a switch between "really reload everything" and "reload, but with moderation" could work. I think that at some time, Ctrl-R did the later, and Ctrl-Shift-R did the former on some browsers.

There are other tricks you can play. Some frameworks (e.g. Rails) add a number for a "stable" resource and increase the number every time that resource is changed.

Overall, it's probably possible to imagine an ideal world where only one such mechanism is used, but because neither browsers nor servers (and the stuff served by them) are perfect, we usually end up with needing more than one mechanism.

Regards,   Martin.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Dec 2016 16:10:50 -1000

>   https://tools.ietf.org/html/draft-mcmanus-immutable

I've said this before, but this is how we should be doing things here:
shipping the specs for deployed code that makes a difference.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 9 Dec 2016 12:16:02 -0800

> On Dec 7, 2016, at 8:03 PM, Mark Nottingham <[email-masked]> wrote:
> 

I support adoption of this draft.  I would prefer some technical and editorial changes,
but that discussion can wait.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 25 Dec 2016 14:33:25 -0500

Adopted.

Patrick, please get it into the repo and submit as draft-ietf-httpbis-immutable-00.

Cheers,

> On 7 Dec 2016, at 11:03 pm, Mark Nottingham <[email-masked]> wrote:
>