4 ms·

I want a cachebust="yes" attribute that invalidates an image when it changes, yet never contacts the server when the image is unchanged.

abraae 5y ago
Why not just give it a new url?
- yummybear 5y ago
  It was kind of tounge-in-cheek, but giving a new url may require a redeployment which isn’t always practical
  - abraae 5y ago
    True. But I can't really think of any app that has the use case where it refreshes images in place. Possibly an app that did that sort of thing would be some kind of gallery or other very image-centric app. And if that were the case, then I would think the image URLs would be dynamic, not burned into the deployment.
chrismorgan 5y ago
A common technique here is to use the query string to control this, with something like ?t=‹timestamp› or ?v=‹version› or ?‹hash of file contents›. Then the server can include proper cache-control headers to say “this is immutable, never going to change, don’t bother asking me if it’s changed”. A cachebust="yes" attribute wouldn’t be useful in practice because the server would either be serving it to everyone, effectively disabling caching (and which would be better done by actually disabling caching with the cache-control header), or need to decide who to serve the attribute to, in which case there are better solutions. In short, cache busting only works if you have some sort of cache key, which is what the query string technique is all about doing.
- theandrewbailey 5y ago
  I've seen tools that complain about query strings for external assets. The reasons for doing so probably aren't important anymore. Instead, I include a last modified timestamp in the URL path, e.g. /files/AXkgRCa3/style.css
jkaptur 5y ago
How would the browser know if the image changed?
intergalplan 5y ago
Huh? That's what HEAD requests and correct HTTP headers are for, surely?
- yummybear 5y ago
  It was kind of tounge-in-cheek though
chias 5y ago
What I have done to accomplish this in the past is some filename shenaniganry with the file's last-modified timestamp: <img src="/path/to/file.[last modified timestamp].png"> PHP code for this kind of thing might look like this: function auto_version($urlpath) { // get a filesystem path $fspath = $_SERVER['DOCUMENT_ROOT'] . $urlpath; // if file doesn't exist, don't mess with the url if (!file_exists($fspath)) { return $urlpath; } // insert last modified timestamp $mtime = filemtime($fspath); return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $urlpath); } Then in .htaccess or equivalent to strip the timestamp back off before serving the file: RewriteRule ^(.*)\.[\d]{10}\.(css|js|png)$ $1.$2 [L] Whenever the file is updated you automatically start serving a new link which points to the same file, and otherwise you can rely on the browser caching. You don't need to mess around with ?params, which also helps semantically because those incorrectly suggest that the resource is dynamic.
sandreas 5y ago
Well, I would prefer an attribute, that is already there for some elements (like css or js files): integrity="<hash>" This would kill two birds with one stone: If it changes in HTML, this means: - Please bust cache - Refetch and ensure, that the fetched file is securely valid And it could be optional for every fetchable resource (img, video, css, js, etc.)

abraae 5y ago

Why not just give it a new url?

yummybear 5y ago
It was kind of tounge-in-cheek, but giving a new url may require a redeployment which isn’t always practical
- abraae 5y ago
  True. But I can't really think of any app that has the use case where it refreshes images in place. Possibly an app that did that sort of thing would be some kind of gallery or other very image-centric app. And if that were the case, then I would think the image URLs would be dynamic, not burned into the deployment.

chrismorgan 5y ago

A common technique here is to use the query string to control this, with something like ?t=‹timestamp› or ?v=‹version› or ?‹hash of file contents›. Then the server can include proper cache-control headers to say “this is immutable, never going to change, don’t bother asking me if it’s changed”. A cachebust="yes" attribute wouldn’t be useful in practice because the server would either be serving it to everyone, effectively disabling caching (and which would be better done by actually disabling caching with the cache-control header), or need to decide who to serve the attribute to, in which case there are better solutions. In short, cache busting only works if you have some sort of cache key, which is what the query string technique is all about doing.

theandrewbailey 5y ago
I've seen tools that complain about query strings for external assets. The reasons for doing so probably aren't important anymore. Instead, I include a last modified timestamp in the URL path, e.g. /files/AXkgRCa3/style.css

jkaptur 5y ago

How would the browser know if the image changed?

intergalplan 5y ago

Huh? That's what HEAD requests and correct HTTP headers are for, surely?

yummybear 5y ago
It was kind of tounge-in-cheek though

chias 5y ago

What I have done to accomplish this in the past is some filename shenaniganry with the file's last-modified timestamp: <img src="/path/to/file.[last modified timestamp].png"> PHP code for this kind of thing might look like this: function auto_version($urlpath) { // get a filesystem path $fspath = $_SERVER['DOCUMENT_ROOT'] . $urlpath; // if file doesn't exist, don't mess with the url if (!file_exists($fspath)) { return $urlpath; } // insert last modified timestamp $mtime = filemtime($fspath); return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $urlpath); } Then in .htaccess or equivalent to strip the timestamp back off before serving the file: RewriteRule ^(.*)\.[\d]{10}\.(css|js|png)$ $1.$2 [L] Whenever the file is updated you automatically start serving a new link which points to the same file, and otherwise you can rely on the browser caching. You don't need to mess around with ?params, which also helps semantically because those incorrectly suggest that the resource is dynamic.

sandreas 5y ago

Well, I would prefer an attribute, that is already there for some elements (like css or js files): integrity="<hash>" This would kill two birds with one stone: If it changes in HTML, this means: - Please bust cache - Refetch and ensure, that the fetched file is securely valid And it could be optional for every fetchable resource (img, video, css, js, etc.)