1. 7
  1.  

  2. 3

    What is practical difference between it and large enough max-age? Is it designed only to avoid “multiple years long max-age” hack?

    1. 7

      When you hit the refresh button in your browser, it’ll re-request every asset that was served with a still-valid max-age. Typically those re-requests will have If-None-Match or If-Modified-Since headers that allow the server to send a HTTP 304 response for them. So assets requested with a long max-age will take at least one RTT to check that they’re still valid, plus a negligible amount of bandwidth.

      Browsers can refrain from re-requesting assets marked as immutable when you hit the refresh button. (I think they may still do so if you hit force-refresh). IIRC the convention on Windows browsers is that the refresh button is F5 and the force-refresh button is shift-F5.

      Some people are used to pressing the refresh button on their browser to make the data that they’re looking at be updated (rather than, or additionally to, pressing any in-app refresh button). Avoiding re-requesting the stuff that is known to absolutely positively never change under any circumstances we promise for realsies makes the website’s UI load quicker after a person presses the refresh button.

      1. 2

        So we have refresh and no really refresh commands, plus cache and no really cache commands. Maybe we should just encode priorities. This is a priority four cacheable object, not to be refetched unless the user issues a level five or greater refresh.

        1. 2

          So we have refresh and no really refresh commands, plus cache and no really cache commands. Maybe we should just encode priorities. This is a priority four cacheable object, not to be refetched unless the user issues a level five or greater refresh.

          And then most of the internet will end up becoming top priority because users should never update anything. And then there will be new priority RfC and we will have priorities and not really priorities.

      2. 4

        User-driven refreshes can override a long max-age, but not an immutable. (I think.)

        1. 1

          You could build offline accessible sites by setting some initial download as immutable.

        2. 2

          Very useful if your asset names contain version info (e.g., commit hash). It’s also a surprisingly big win for social sites where people click refresh often. See https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/

          For toying with it, I set up this demo page at https://immutable.on.web.security.plumbing/

          1. 1

            Shameless plug, I wrote a toy pastebin server called yasuc, whose pastes are identified (and located) by the SHA-256 of their contents. Immutable responses would be most excellent for this use case.