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

On 2016/12/08 13:55, Mike Bishop wrote:
> 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?

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.

Received on Thursday, 8 December 2016 05:20:15 UTC