- From: Alcides Viamontes E <alcidesv@zunzun.se>
- Date: Mon, 27 Jun 2016 17:02:38 +0200
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAAMqGzZHHUtYGV_G+gfYLh03-gTOELajf-JO4G+hO4wNOqC5oQ@mail.gmail.com>
On Mon, Jun 27, 2016 at 2:41 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 27/06/2016 9:37 a.m., Raphaƫl D wrote: > > On Wed, 22 Jun 2016 13:39:39 +0200 Alcides Viamontes wrote: > > > >> Yes, this is related to caching in general. And it is the reason > >> people have to add query strings for doing cache busting. This problem > is a > >> separate issue, but it interacts with cache digests in that old version > >> of assets are kept in the cache and therefore in the cache digest and > the > >> origin have no way of removing it. The origin can only create a new URL > >> (say, via a new query string) that gets added to the cache and the cache > >> digest. > > > > (email subject renamed to avoid polluting the "Cache Digests for HTTP/2" > > mailing-list thread) > > > > Hi, > > > > I read this incidentally meanwhile trying to understand what alternative > > to cache-busting exists. > > I'm stretching my head to find which overlooked IETF-http or W3C concept > matches. > > > > > > Nowadays most CMS, javascript/css-frameworks feature cache-busting > > (usually using query-string) which is considered as the unavoidable > > answer to the "can't forcefully refresh browser cache" issue (and web > > traffic pattern). > > > > > > Among the facts/reasons given are: > > > > 1) web-applications support the fact that some webserver set far-future > > Expires times for assets (css, js, fonts) > > The existing Best Practice is for redesigns to change the names of their > objects slightly *iff* the object has changed enough to warrant it. > Enough to do cache busting without query-string, but also to retain > backward compatibility with older versions of the application requesting > old assets. > I do think that having to change the names of modified assets is a bit sad. Wouldn't it be nice if etag validators were enough? On the other hand, if a bug needs to be fixed in say "login.js", one would certainly want to propagate those changes instantaneously. As it is now, I can not have my pie and eat it :-(
Received on Monday, 27 June 2016 15:03:36 UTC