The CDN failures aren’t coming through maxcdn. It looks like they are all in the “uploads” folder. Have you changed the wordpress configuration to use the CDN for the uploads (I have a link to the configuration setup earlier in the thread):
For the caching headers, is there a configuration in W3 Total Cache to set long expires on the combined files? It looks like those two are the combined css and js files from W3 Total Cache. Worst case you can just set a .htaccess rule in that folder to set a long expiration for css and javascript but a config setting would be easier.
I have not changed the WP config, and I am not seeing “(I have a link to the configuration setup earlier in the thread)”…in this thread or are you referring to a different thread?
The only setting in W3TC for expired headers is through a check box that says:
check/uncheck - Set expires header
Set the expires header to encourage browser caching of files.
I now have the latest 0.9.1 version of W3 Total Cache…I just figured out the expired header time…it was set at 3600 seconds (1 hour), so I changed the HTML and Combined CSS & JS both to 31536000 seconds (1 year)…does that sound right? Tho other Wordpress config is handled through the CDN section of W3 Total Cache where I set up a cname to my MaxCDN pull zone and put the cname into W3TC…I believe that is what this link is referring to which seems to all be handled by W3TC.
Yep, 1 year should be fine. It looks like w3tc generates unique file names any time it changes so there shouldn’t be anything to worry about there. The initial test results you sent didn’t have any header at all though (not even 1hr) so hopefully the update fixed that.
The CDN should pass the original expires through. Try hitting the original file using the non-CDN path and see if it has the expires headers. From their config screen:
How do I change the default cache time?
The default caching time is 1 day (24 hours) for all file types. It will respect the ‘Cache Control’ header from your Origin Server if the ‘Cache Control’ header is present. If you need any further custom edge caching settings, please Contact Us.
Interestingly enough that should override the lack of headers from your origin so it might not hurt to contact them. Worst case they can override what you have set on the origin but it would be best to leave it as a passthrough.
You should try flushing the CDN cache through their UI and if that doesn’t fix it contact their support. Looking at the request directly to the origin files it looks like they are properly set:
