Cache static

I am trying to implement CloudFront CDN with Custom Origin (CloudFront pulls the data from my web server). But when I test the page, I see this:
I use Drupal and I put on the CDN the ImageCache files, generated from Drupal. I use Nginx instead of Apache, and php-fpm.
I’ve configured Nginx to set correct headers, but somehow this is not reflected by the CloudFront.
I use this directive to serve the images from Nginx:

serve static files directly

location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|swf|flv)$ {
access_log off;
expires max;
add_header Cache-Control max-age=315360000;

But maybe this is not enough? From the graphic I see, that CloudFront don’t get my Expire headers. Any advice is welcome! Thanks in advance!

It does look like you header is making it through, I think it may be set too far into the future though (try 1 year):

HTTP/1.0 200 OK
Server: nginx/0.8.49
Date: Mon, 22 Nov 2010 06:39:12 GMT
Content-Type: text/css
Content-Length: 71164
Last-Modified: Sun, 21 Nov 2010 16:16:46 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Age: 23628
Vary: Accept-Encoding
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: b792921134321f896b4f6b96be2ade80089050d3195bc0ae77495d1b4609355c94715266cd11fccf,8396cb836f64a8113dba66256abcb69403277a25932caa7668a4e1812b7553ccb379ccdeb24efe36
Via: 1.0 (CloudFront), 1.0 (CloudFront)
Connection: keep-alive

FWIW, it doesn’t look like cloudfront is gzipping the content either. Do you also use S3 for parts of your site? If not then there are probably easier/better/cheaper options for just a straight origin-based CDN.


Thank you Pat!
I tried to lower it to 1 year and this is the result:
it seems, that again CloudFront instructs the browser to revalidate.
I am little confused, because when I look 1st view of webpagetest it tells me in Optimization checklist, that caching of static objects is done, but in second view all files from the CDN are in red and No max expires notice.
I don’t use S3. I can’t access the files on the cloudfront, because they are pulled from CloudFront with Custom Origin, so the solution to upload them by hand with tool with custom header is something that can’t help.
I use for now CloudFront because I want the files to be closer to my country - Bulgaria. The other origin based CDNs that you talk about can be fast to Bulgarian users too? I can test and if there is not initial tax, but pay as you use, I can use them. CloudFront don’t ask me for money in the beginning of the usage, so it’s easy to test them :slight_smile:

I’m pretty sure the Vary: Accept-Encoding header breaks caching of images for IE.

As far as performance goes, it looks like Cloudfront’s closest edge location to Bulgaria is probably Frankfurt: Low-Latency Content Delivery Network (CDN) - Amazon CloudFront - Amazon Web Services - that’s actually a common place for CDN’s to have a pop so I don’t think you’ll have problems finding an alternative that is a lot easier to use.

I don’t think it’s a secret that I’m a fan of MaxCDN (use them for WebPagetest) and they have a discount available here: which brings costs down to around 3 cents a GB for the first year (or TB) and even at normal costs it’s still quite a bit cheaper than cloudfront.

One of the other forum users has had good results with CloudFlare: which is a free CDN and has an edge location in Amsterdam: Cloudflare Status

Thanks! I know MaxCDN, already read all the information about it and it’s in my first recomendation list for CDN for now.
I will try this Vary with Nginx. So you think, that this is IE problem to see that the images are cached?

Yep, can’t find the thread about it right now (know it was discussed somewhere on the forums) but here is a blog post on it: Internet Explorer and cacheing: beware of the Vary - Crisp's blog - Tweakblogs - Tweakers

That isn’t causing the problem with your css (my guess is that that is because of the date that is too far ahead) but the Vary: Accept-Encoding header definitely breaks caching of images on IE.

I had the same issue with nginx when i added the vary header…

The workaround is,…

  1. Remove the vary header directive
  2. use the gzip_vary directive … Module ngx_http_gzip_module

What this does is it only adds the vary header on gzipable content… So no more vary headers for images…

Fiddler | Web Debugging Proxy and Troubleshooting Solutions confirms this behaviour(?)

Patrick, it’s ok now.
I am not sure about the Vary. I think that this didn’t help. My problem was because I had two Cache-Control headers and maybe because I had mistake - didn’t put in “” - example: “max-age=number”
Recreated the cloud distribution and now everything is OK :slight_smile:

BTW, I am not so sure about Vary, I’ve added it but didn’t seem to help, so I’ve made few other changes, and finnaly recreated the Cloud Distro, to get fresh content. So maybe Vary is one of them. Thanks to all for the support! :slight_smile:

Fear not, the latest implementation of IE gets vary encoding right. That doesn’t help with older versions though so there is a better overall method, filematch for images (since only image vary throws off IE).

<FilesMatch “.(jpg|jpeg|png|gif|ico)$”>
Header set Cache-Control “max-age=31530000”
Header unset Vary
Header unset ETag
FileETag None

And yes, Godaddy shared will allow you to make this work in .htaccess. I see negative threads from frustrated webmasters all over about them so I figured they deserve credit for getting it right, sometimes :slight_smile: