A very cheap trick to stop images from being cached is to diddle the URI in the <img> element on the page. Instead of emitting:

<img src="thumbnail-left.png">
<img src="thumbnail-right.png">
[download]

Into the outgoing page, add a bogus GET parameter that makes them unique:

<img src="thumbnail-left.png?4608fe05888c">
<img src="thumbnail-right.png?4608fe0ab9b9">
[download]

Which, unless you have some weird'n'wacky image handler, will be ignored by your server and the client will be forced to reload the images each time due to the GET parameter, which will inhibit its ability to cache.

And in case you were wondering, I generated the above with sprintf "%x%0x\n", time, rand(65535);. Adjust as appropriate.

This is far less hassle than having to fiddle around with cache/no-cache parameters.

Duh, of course. I've done something similar with my Ajax calls, because IE caches the GET requests. Cheers for pointing that out

Images are sent in a separate http request than your html page, so you probably need to send a non-caching header with each image. Offhand, the only way I can think of doing this is to send the images through your script where you can add your own header. You might check the server documentation to see if there is a configuration directive to send non-caching headers.

ah, I understand now. My no-caching efforts were in vain...

Not entirely sure I understand your requirements... but why do you need to disable caching at all? As long as each image is corresponding to a unique URL, things should work as intended. Let's assume you have three images. So, instead of having something like

   -----    ----------   ---------   -----------    -----
  | <-- |  | left.jpg | | mid.jpg | | right.jpg |  | --> |
   -----    ----------   ---------   -----------    -----
[download]

and then changing the image content that's delivered as "left.jpg" etc. when the --> button is clicked, it's proably easier to just update/rotate the URLs. For example, if you initially have

   -----    ----------   ---------   -----------    -----
  | <-- |  | img1.jpg | | img2.jpg | | img3.jpg |  | --> |
   -----    ----------   ---------   -----------    -----
[download]

   -----    ----------   ---------   -----------    -----
  | <-- |  | img2.jpg | | img3.jpg | | img4.jpg |  | --> |
   -----    ----------   ---------   -----------    -----
[download]

i.e. "img2.jpg" remains the same image (so the browser can reload it from its cache). It'll just be displayed in a different place.

Even if your requirements are not quite as simple as that, it should still be possible to always make sure that, if the content of the image changes, it gets a new URL (so cache lookup will surely fail). At least, that approach should always work as a last resort.   But maybe I've completely misunderstood what you want to do... :)

Having said that, if you still want to go the other route trying to disable client side caching, you might want to look into using mod_headers, which lets you set/add specific custom headers for certain URLs, even if they're static, like images.

BTW, there's a neat caching test page (AJAX-based), to give you an idea of which caching features actually do work in current browsers... (things have gotten better, generally, but there are still a number of more sophisticated, unresolved issues)

hmm ... I probably didn't explain myself very well. I am rotating an image (using Image::Magick's Rotate method) not changing the image order. So nothing about the web page has changed - but the image on the disk itself has rotated. I can't change the name of the image to prevent caching (other than to add redundant query info as above) as it's used throughout the system and by more than one module.

mod_headers could be useful, though. Thanks

Aside from cache-related pragma's and standard content-expiration, you may wish to check out the 'ETag' HTTP header, which seems to be favoured by Internet Explorer for this kind of thing.

Using ETag, you uniquely idenify each 'version' of a resource, so if you want it to refresh, you send a different ID.

I find it better than appending ?12309821 to a request because:
• my logs arent filled with random numbers
• 12309821 adds nothing to the document, semantically speaking.
• the ETag header is generally left unmolested by internet proxies.

-David

mod_headers contain directives that allow you to add headers to requests. You might also be interested in mod_expires. Using <FilesMatch>, <Directory> or <Location>, you can limit the requests to which the headers are added.