views:

19

answers:

1

In Chrome and Safari a remote image included on my site never seems to get requested with caching-friendly headers (If-Modified-Since, etc) despite the server returning the appropriate information. Local resources, on the other hand, are requested with these headers. In contrast Firefox requests the remote resources with caching-friendly headers.

This is for images on S3 though I don't think it's unique to S3...

Update: Here's the actual request I'm seeing via Chrome Resources panel.

Request URL:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
Request Method:GET
Status Code:200 OK

Request Headers

Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Cache-Control:max-age=0
Referer:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4

Response Headers

Cache-Control:public, max-age=86400
Content-Length:4074
Content-Type:image/png
Date:Wed, 30 Jun 2010 12:15:42 GMT
ETag:"7e4739d5527ada6bb327f1e27ee656ef"
Last-Modified:Tue, 29 Jun 2010 13:40:08 GMT
Server:AmazonS3
x-amz-id-2:MKTS28Zu4zTsWFjXUTzvmRY214TO9LTKTxtgW1psWKa/JY2pnwmO9rxs8fyHd/O/
x-amz-request-id:F6047ADD0FD6D885
x-amz-version-id:O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp

Repeating the request doesn't lead to any additional headers being sent by Chrome (and as mentioned before, Safari). In contrast, quickly refreshing in Firefox gives me the following:

Status: 304 Not Modified

Response Headers

x-amz-id-2  IbhwfAP7FhIN7jtn2FrsjOkVZ8sIKJjv5llevKgw04y2xM+29GSFdGyQNXjiBaMY
x-amz-request-id    258F30A4CC2AC870
Date    Wed, 30 Jun 2010 12:19:55 GMT
Cache-Control   public, max-age=86400
Last-Modified   Tue, 29 Jun 2010 13:40:08 GMT
x-amz-version-id    O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp
Etag    "7e4739d5527ada6bb327f1e27ee656ef"
Content-Type    image/png
Content-Length  4074
Server  AmazonS3

Request Headers

Host    mobtest.s3.amazonaws.com
User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  300
Connection  keep-alive
If-Modified-Since   Tue, 29 Jun 2010 13:40:08 GMT
If-None-Match   "7e4739d5527ada6bb327f1e27ee656ef"
Cache-Control   max-age=0

Update 2: And now I see Chrome caching the content. Strange... I'm going to close this question and give Marc the answer.

+1  A: 

If the server is sending back an "Expires" header that is somewhat far in the future, then the browser may be deciding that the content is still fresh enough in it's cache and that they don't even need to make a request to the server at all. You may want to review the headers being sent back from the server and ensure they are set to reasonable values. See http://stackoverflow.com/questions/499966/etag-vs-header-expires/500103#500103 for more information. Feel free to update your question with the actual URL or headers that are sent back from the server.

Marc Novakowski
Thanks, Marc, but I believe Chrome is actually making additional requests. I've updated my original question with the request-response cycles in Chrome and Firefox.
pr1001
That's very strange - it looks like Chrome isn't even sending the "If-Modified-Since" or "If-None-Match" headers in the second request - which would guarantee the server sends the file back again. Is your Chrome configuration set up to the default values?
Marc Novakowski
And today it decided to send them... My only guess is that it had to do with my `max-age` directive and that I had last visited the site within the `max-age` timeframe.
pr1001
You may also want to try using a proxy such as Charles or Fiddler2 to see the actual HTTP traffic - who knows.. for some reason or other the native debug tools in Chrome and Firefox might not be showing all the headers.
Marc Novakowski