Is there a way to force browsers to refresh/download images?

Question

I have a problem where users are reporting that their images aren't being uploaded and the old ones are still there. On closer inspection the new images are there, they just have the same name as the old one. What I do on the upload is that I rename the images for SEO purposes. When they delete an image the old index becomes available and is reused. Therefore it has the same image name.

Is there a way to (i thought maybe there might be a meta tag for this) to tell the browser to not use its cahce?

The better answer is to rename the image to something totally new. I will get working on that but in the mean time is the quick solution while I work on the bigger problem.

Solution 1

Append a query string with an arbitrary unique number (or time, or version number, etc.):

<img src="image.png?80172489074" alt="a cool image" />

This will result in a new request, because of the different URL.

Solution 2

It's tough. You really want images to be cached, but then you don't want to cache them once a new ones available:

• Using expires header with a date in the past prevents any caching. Bad
• Adding a "cache busting" parameter ?342038402 can fix the problem, but can also prevent the image ever from being cached, which is not what you want. Bad.
• Using expires header with a short (lets say 1 hr) expires is better... after an hour the user will see the image, but your web server won't have to serve it every time. Compromise, but what time works? Not really feasible.

The solution? I can think of two good options:

• Look into eTags, and your ability to use them. These are designed for this situation. The browser will explicitly ask your server whether the file is up-to-date or not. You can just turn this on in apache if you don't have it aleady.
• Create a new URL for each new image (and use a far-future expires header). This is what you are working on.

Solution 3

My favourite PHP solution:

<img src="<?php echo "image.jpg" . "?v=" . filemtime("image.jpg"); ?>" />

every change of file "create" a new version of the file

Solution 4

Append the current datetime to the image src:

<img src="yourImage.png?v=<?php echo Date("Y.m.d.G.i.s")?>" />

Solution 5

You can put http-equiv in <meta> tag which will tell browser not to use cache (or even better -- use it in some defined way), but it is better to configure server to send proper http cache headers. Check out article on caching.

Still, some browsers might not support all of http standard, but I believe it's the way to go.

View more solutions

Comments

[Michael Krelin - hacker]

+1, but strictly speaking it's not different filename ;-) The filename component is the same, but the URL is certainly different.

[Michael Krelin - hacker]

Gubmo, unique is a bit too much, the best in this case would be to add file's mtime — this way it will only be reloaded when needed.

[rahul]

The best way will be to use a version number of the release.

[Michael Krelin - hacker]

RageZ the problem here is that you will also have to get certain browser's developers consult the RFC.

[RageZ]

yes ... but at least that the relevant document. after implementation glitch is kind of ...

[Michael Krelin - hacker]

I'm all for proper implementation, but we have to deal with reality.

[Gumbo]

@hacker: Randomness doesn’t guarantee that two generated values may not be identical. But uniqueness does guarantee that two generated values are not identical. And isn’t the modification date of that file a unique datum to that file?

[Michael Krelin - hacker]

Gumbo, you can, of course, use hash over file contents, but basically, you want the file to be reloaded whenever it is modified and this is when the time stamp is updated in case of normal workflow. You don't want the file to be unconditionally reloaded on each request. Besides, you don't want it to be unique to file — the uniqueness is provided by the uniqueness of filename+query string combination.

[samuil]

On the contrary, using workarounds supports browsers' bad support for these ideas ;) I see your point, and I know further discussion usually leads nowhere - something is "better" but does not work as intended, something is "worse" but do work. It is all up to webdev, what will he/she choose.

[RageZ]

Most of browsers implement that correctly, back to the IE6 days that was ugly but now should be fine.

[Doin]

The browser won't (shouldn't) use the cached version if it requests the image from its HTTP cache. However, if the browser has an in-memory copy of the image, it will sometimes just use that without ever querying its cache. Add a unique fragment identifier to the image URL to ensure it doesn't use an in-memory copy of the image.

[michaelmol]

<quote>"Adding a "cache busting"... Bad." </quote> This is not true, it will force the browser to cache this specific verions for the image, so image.png?342038402 will be cached as that version. If you have the same image with different query string that is bad.

[AZ Chad]

michaelmol, but then you'll have to manually create a new random number each time the image is changed? I get you don't want it to never cache. using this technique I don't see a way to just upload the image to it's location with the same name and have something programmaticly update the path with a new random number

[RicoBrassers]

@ChadMizner If using PHP, you could use PHP's filemtime(string $filename) function in combination with the "cache busting" parameter. That way, the URL for that file will change everytime, the requested file was changed. (Credits to Michael Krelin - hacker).

[Shumoapp]

You could as well turn off caching, because your example will force the browsers to download the files each time (because the timestamp will change each second). I would suggest removing the i and s at the end, so the timestamp changes every hour. This way the browsers will download the images only once per hour. "Y.m.d.G"

[Ben Bozorg]

Doesn't matter that you change the value attached to the image url or not. Once there is SOMETHING at the end, your browser will get a fresh copy from the server (Even if that value didn't change). That's why it is BAD!

[Toby Speight]

Depends on the browser - a lower-latency technique is to use If-Modified-Since header in a GET request. The consequence is still the same - make sure that you correctly report the file's modification time, so that cache invalidation works correctly.

[Robert Sinclair]

but if you add ?123 for example once and don't touch it, it will still cache that image right. I'm assuming it will only "recache" if you change it to something different than ?123

[knittl]

@RobertSinclair yes exactly. Each URL will be cached independently. That's why you could for example append the file modification time, a version number, or a file hash to force a "browser refresh" if the underlying file changes.

[Gianluca Demarinis]

try to use last-modification-date of file, instead. so you can download the new file only if it was changed

[Daniel Wu]

Use ?YYMMDD-HHMMSS of the time the user updated his/her image. This way the image will be reloaded only if it's changed. Not on each browser reload.