Bug 127318 – Does not properly cache image sources that are accessed more than once if header is "expired".

• Status: NEW
• Component: Images

Also described in:
http://code.google.com/p/chromium/issues/detail?id=336292&thanks=336292&ts=1390259561


-= Steps to reproduce: =-
1) Make sure your expiration date is "now" (or less). EG, in Apache's .htaccess, you should add:
ExpiresActive On
ExpiresDefault "access"

2) Load an image via Javascript.

3) After some time, load another image with the same SRC.


-= Expected: =-
The first time the image is loaded, the server's caching rule requires that the image is checked for freshness. (step 2)

The second time the image is loaded, it is expected that the caching rule is not used and that no check for freshness is used.


-= Problem: =-
On most Webkit-based browsers, in-process caching is not done if the image is "expired" at the beginning of the initial page load.

There is a workaround to make pages always refresh when the in-process caching is done -- append a unique identifier parameter.

There is also a full workaround in the other case -- use <canvas> images exclusively.

I cannot find the relevant W3C spec, and I suspect there isn't any.

With this bug in place, one cannot simply pre-load images by adding their SRCs in a URL and creating new Images for them. One has to either have a global object that specifies each image SRC's height/width/completeness, or (to fix blinking issues) use <canvas> objects exclusively. This is somewhat of an inconvenience for web development.


These are the browsers that cache the image once and do not try to re-validate:
IE11
Firefox (at least starting from 25)
Safari Windows 5.1.7

These browsers try to re-validate each time (all Webkit-based or derived):
Chrome / Chrome on Android
Safari 7 (except for Safari Windows 5.1.7) / Safari on IOS.
Opera

[Alexey Proskuryakov]

See also: <https://code.google.com/p/chromium/issues/detail?id=330554>.