static resources not cached?

first of all: “wonderful tool!” :slight_smile:

Second, I have a test where I see requests to static content in a repeat view, where I’ve expected the browser to cache the *.js, *.css and *.png files:

Can someone spot, why the resources are not cached?



Same here, I’ve been running testing for a couple of month, it’s only recently (around some default setting have changed) that the contents are no longer cached, I haven’t seen much setting to toggle it so my guess is that our host only can control that.

Would be really nice to have it working like before.


PS: I was using Dulles defaults, I switch to Chicago and the browser is caching content, I guess the settings are not the same.

This tool is really awesome !!

I just saw, that the cloudfront server responses with HTTP 1.0. Maybe that’s the reason, that the IE is more conservative.

It looks like there are 2 sets of cache-control headers in the responses:

Cache-Control: max-age=31536000, public
Cache-Control: no-cache="set-cookie"

I haven’t done much testing with a field-specific no-cache setting before but I wouldn’t be surprised if that was causing the issue.

Hm, and in my case that header is served via a cdn where cookies aren’t set anyway. Thanks for pointing that out, I will try to get rid of the second Cache-Control header.

I boiled this down a little bit and thought maybe someone came across the same issue. My setting is a home grown http server running a rails application on a EC2 server. Before that server is a load balancer with Session-Stickiness enabled. To serve static files, CloudFront is used and configured to use the load balancer as orgin server.

Because of the session stickiness, the LB adds the ´Cache-Control: no-cache="set-cookie"´ to the response. The orgin server serves the files with the ´Cache-Control: max-age…´ header. According to the http 1.1 rfc, the headers are fine and must be read like one header with 3 values.

One the other hand, the CloudFront server is using http 1.0 and IE9 seems to ignore the first header. With IE10 this seems to be fixed.