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


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.


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.

  • I think it needed time to distribute the files to edge locations. That's not how CloudFront works. It is only pull-through, there's no push from origin to edge. If you change an object that is already cached in a particular edge location, you have to wait for it to expire, or create an invalidation request to evict it from the cache so that the next request will fetch a fresh object. Apr 16 '16 at 20:47

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.

  • 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.
    – jarvis
    Apr 16 '16 at 15:17
  • 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.
    – Tim
    Apr 16 '16 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.