Cache-Control not working in AWS S3 object Metadata

Question

Follow-up to my original question: No Cache-Control Header for files from AWS CloudFront with S3 Origin

Im serving up static files using AWS CloudFront with AWS S3 as the origin. I tried to set the Cache-Control header for my objects using AWS web console as instructed in the answer in my original question (link above). And when I access the file using the AWS S3 link, I can already see the Header I added: Cache-Control: public, max-age=31536000.

The problem is that the browser does not respect the header. When I reload/refresh the same link, I get a 304 - Not Modified response instead of a 200 (Cached) response.

I also tried the value max-age=300 (no Public) and also tried the value inside " " but I always get the 304 response. I also tried to add the Expires header from S3 but the same results.

How do I make the browser respect the cache header? I want to leverage on browser caching and save cost in using AWS.

Additional note: My S3 Bucket is not set for Static Website Hosting. Just in case that has something to do with this.

EDIT: Below are live HTTP Headers

https://cdn.example.com/path/logo.png

GET /path/logo.png HTTP/1.1
Host: cdn.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.example.com/
Connection: keep-alive
If-Modified-Since: Tue, 12 Apr 2016 10:29:24 GMT
If-None-Match: "xxxxxxxxxxxxxxxxxxxxxxxxxxx"

HTTP/1.1 304 Not Modified
Connection: keep-alive
Date: Sat, 16 Apr 2016 09:33:08 GMT
Etag: "xxxxxxxxxxxxxxxxxxxxxxx"
Server: AmazonS3
Age: 67885
X-Cache: Hit from cloudfront
Via: 1.1 xxxxxxxxxxxxxxx.cloudfront.net (CloudFront)
X-Amz-Cf-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx==

EDIT: I get the 200 response if I reload and 304 Not Modified if I hit enter on address bar URL. Also, Google assets in the same page load are responded with 200 (from cache) and not with a 304.

UPDATE:

Online tests currently detecting that files are already cached. Did the test on http://www.webpagetest.org/ and http://tools.pingdom.com/. Also with Google Page Speed. I think it needed time to distribute the files to edge locations. Which is weird since I was changing the file names with every edit for changes to happen immediately. But as far as caching was concern, it might needed time to distribute the cache to edge locations. Still doing a few more tests.

Solution

200 is the ok response, it means the server has sent the requested resource. 304 not modified means the object is in the browser cache, the browser has checked.

If you've hit reload you may be running into a browser issue, not a server issue. You've told it to reload, so it goes to the server. Try loading that resource by going into the URL and hitting "enter", not "reload".

Try the "live http headers" plugin for Firefox, it shows what's going on well.

Based on what you've said I don't think there's actually a problem, but you'd need to post the output from Live HTTP Headers for us to be sure. If you do that don't just use one resource, load a static html page and have it refer to a jpg on the CDN.

Comments

[jarvis]

I'm still getting a 304 right now in my browser. But tools.pingdom.com and webpagetest.org already detected the cache. And so did Google Page Speed. I guess it needed time to propagate? In my tests I often changed the file name to trigger it to fetch a new data but I was consistently getting a 304. I's doing a few more tests and will mark this as answered.

[Tim]

Read up on how how http works with 304 and such, I think it's just a little thing for you to learn about testing methodology.