Image not stored in cache even though headers are set

Question

The last few hours, I have tried to figure out, why the following image is not cached in the browser, after it is requested the first time:

http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg

I understand that the correct headers have to be set, and currently the response header looks like this:

HTTP/1.1 200 OK
Date: Sat, 04 Jan 2014 16:35:53 GMT
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev
    Perl/v5.16.3
Last-Modified: Sat, 30 Nov 2013 01:37:52 GMT
ETag: "1dac5-4ec5afebf3c00-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=2592000
Expires: Mon, 03 Feb 2014 16:35:53 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/jpeg

As you can see, the "Expires" header is set to "Mon, 03 Feb 2014 16:35:53 GMT" and I also included a "Cache-Control: max-age=2592000".

Can you help me and tell me what I am missing? Your help would be very much appreciated.

Thanks!

I think this has something to do with browser. When you try to access an image directly, it gets the latest copy. But if the same image is referenced in another page, it would behave normally and cache it. — Parthik Gosar, Jan 04 '14 at 17:13
Thank you for your reply! Unfortunately that doesn't seem to be the case, though. The image is used as background image on the following page: [link](https://runrpg.net) On this page, the image isn't cached either. — DerJacques, Jan 04 '14 at 17:37
A bit OT, but: Is there a reason for compressing an image? I would expect this to *increase* the transferred content. — DaSourcerer, Jan 04 '14 at 17:56
Now I'm quite new to this, but I thought that image compression means that the transferred content decreases? From tests I've found that in this case the size of the image decreases by 11%, but maybe I misunderstand something? — DerJacques, Jan 04 '14 at 18:18
@DerJacques: That can only happen if they haven't been compressed through the JPEG algorithm properly in the first place. In any case, HTTP compression is really the wrong place for this. — DaSourcerer, Jan 04 '14 at 18:27
Okay, thank you! I will definitely change that. Fortunately, it should be very easy to do. I suppose you don't have any answer to the original questions? Any idea, why no images, css files or js files are cached on [runrpg.net](https://runrpg.net)? — DerJacques, Jan 04 '14 at 18:38
I'm still scratching my head over this. I'd try to add `public` to the `Cache-Control` header if I were you. — DaSourcerer, Jan 04 '14 at 18:43
I tried to do that (and it is currently 'enabled'), but there's still no difference. Really strange behavior, but there's something I must be missing.. — DerJacques, Jan 04 '14 at 18:48
It's especially puzzling how there's hardly any difference to [this](http://stackoverflow.com/a/3001556/3012385) answer ... My Firefox is misbehaving as well, I almost suspect there's something wrong with your server. — DaSourcerer, Jan 04 '14 at 18:54
I guess you are right! I just find it strange that the browser is dependent on the server, even though the cache-headers are set correct. Maybe the server should return 304? — DerJacques, Jan 04 '14 at 18:59

score 2 · Accepted Answer · edited May 23 '17 at 12:28

This is most likely due to your server not validating ETags correctly. While cache validation through the Last-Modified header works perfectly:

$ HEAD -H "If-Modified-Since: Sat, 30 Nov 2013 01:37:52 GMT" http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg
304 Not Modified
Cache-Control: max-age=290304000, public
Connection: close
Date: Sat, 04 Jan 2014 19:01:30 GMT
ETag: "1dac5-4ec5afebf3c00"
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev Perl/v5.16.3
Expires: Thu, 09 Jan 2014 19:01:30 GMT
Client-Date: Sat, 04 Jan 2014 19:01:30 GMT
Client-Peer: 80.70.3.110:80
Client-Response-Num: 1

The same cannot be said with ETags:

$ HEAD -H 'If-None-Match: "1dac5-4ec5afebf3c00-gzip"' http://runrpg.net/assets/images/screenshots/placeit_outdoor_wide.jpg
200 OK
Cache-Control: max-age=290304000, public
Connection: close
Date: Sat, 04 Jan 2014 19:02:24 GMT
Accept-Ranges: bytes
ETag: "1dac5-4ec5afebf3c00"
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.3 mod_perl/2.0.8-dev Perl/v5.16.3
Vary: Accept-Encoding
Content-Length: 121541
Content-Type: image/jpeg
Expires: Thu, 09 Jan 2014 19:02:24 GMT
Last-Modified: Sat, 30 Nov 2013 01:37:52 GMT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: origin, x-requested-with, content-type, X-Titanium-Id
Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Origin: http://127.0.0.1:8020
Client-Date: Sat, 04 Jan 2014 19:02:24 GMT
Client-Peer: 80.70.3.110:80
Client-Response-Num: 1

Bottom line: The problem is your server, not any clients. This seems to be a known issue with Apache 2.4.x. A quick solution to this is by switching ETags off:

FileETag None

Thank you very much for your help! This answer has been very helpful and I will look closer into the ETag validation on the server side. At least now I know where to look! :) Thanks again! — DerJacques, Jan 04 '14 at 19:07
Quick addition: The cache works just fine, when I use your quick solution and turn off the ETags. Thanks again! — DerJacques, Jan 04 '14 at 19:13
@DerJacques Not at all. Thanks to your question, I am now aware of this issue ;) — DaSourcerer, Jan 04 '14 at 19:14

Image not stored in cache even though headers are set

1 Answers1