I have a rails application hosted on Heroku. Recently we switched to use a CDN (cloudfront) for our assets. Although we faced problems with CORS, we were able to get it all sorted out with the font_assets gem and proper tuning of cloudfront.
We are having a few select users (two reported so far, each on latest chrome 40+) not downloading the assets and therefore having no styling of the page.
Why would this happen to select users? Some things I've noticed that might help:
There are a lot of 3xx responses recorded in cloudfront (more than
2xx)
Around the time that the user loaded an unstyled page, a 304 response was returned for the css file.
Related
I created a domain on CloudFlare, a website with HTML and CSS, hosted my bucket with those files on S3, and integrated terraform for deployments. When I kick off terraform apply and run the aws cli command to update the S3 bucket, formatting changes like text show immediately but my CSS changes like font sizes and colors take several hours to be visible. How can I make both types of changes visible quickly?
I tried hard reloading my browser, clearing cache, and setting auto minify on cloudflare. I haven't tried gzipping my css and min.css files, a little afraid I might break something. I'm unfamiliar with front end development. Suggestions?
For a proxied ("orange clouded") DNS record, Cloudflare applies a default caching behaviour. This includes default cached file extensions such as CSS files. The default behaviour, caching and extensions cached are documented here.
When you do a release on your origin (S3 bucket), you could purge the cache so that the old cached versions are discarded and new ones will be pulled and cached. You can also override the cache behaviour by using Page Rules. By the way, Page Rules (and other Cloudflare settings) are also manageable via Terraform.
I'm running a Rails 3.2 app on Heroku. For about a week we were serving assets via CloudFront by setting config.action_controller.asset_host to our CloudFront URL in our config/production.rb file. This was working successfully.
This past weekend, however, I noticed that after a deploy to production our website looked very off, and the reason was that it was serving stale CSS. I looked at the css file it was serving (using inspect element in Chrome), and the CSS was an md5-hashed application.css file coming from CloudFront. I removed the asset_host line (so that assets would be served directly from our app) and deployed again (without changing any css), and noticed that the site, which now looked fine, was serving application.css with a different md5 hash.
So it appears that for some reason, CloudFront was serving an old version of application.css, and I'm guessing this is because our application was telling users' browsers to serve an old version of application.css.
To add one more variable: we do cache the home page and part of our our layouts/application.html.erb file (which contains the stylesheet tag), but on each deploy we clear the cache via Rails.cache.clear.
So my best guess is that Rails.cache.clear might not be properly invalidating the cache. We use the dalli memcache client, if that helps.
Any insights or suggestions would be greatly appreciated!
Update:
I tried moving the CSS out of the cached block and re-enabling CloudFront, but the CSS still appears broken. So it doesn't appear to be related to caching the header.
Update 2:
It looks like this is a CloudFront issue, because when I inspect element and change the CSS URL in the to our root domain (instead of the CDN domain), the CSS renders correctly.
Since a md5-hash collision is extremely unlikely, it seems like CloudFront is serving the wrong CSS file when I'm requesting the correct md5-fingerprinted CSS file. Any ideas?
assets are not automatically synced to your CDN when you deploy an app on heroku. In the deployment script on heroku it does do the rake assets:precompile task but it does not then place them into your CDN. You'll have to create some sort of mechanism to do this on your own on deployment of your app.
Somebody else asked a similar question and you might want to have a look at what the suggestions were there: Rails 3 automatic asset deployment to Amazon CloudFront?
Everyone in our web development unit get Firebug "Aborted" errors on random css, js and image objects when we load one of our Drupal 7 sites in https (and a force-refresh). We don't know when the problem started. Site was created about 2 years ago, and about 6 mo. ago we started getting CSS / JS / Image objects not loading when we force-refresh the page cache or clear the Drupal js / css file aggregation.
Researching online suggests that there is an AJAX interference problem, but I haven't seen that in our case.
No errors if:
Page requested via HTTP / Port 80
Objects already in cache
Viewing the site in Prod (has a signed cert)
Errors even if:
Upgrading Firefox and Firebug
Turning off js / css aggregation
Using Google Chrome
The server logs indicate no request for those files at all, so it's like the browser never sends the request.
The cert is self-signed.
Must be some certificate problem. Maybe it's revoked, expired or something.
I use both Telerik and Microsoft CDN, for their respective AJAX toolkits. Both work great 99% of the time. However, I was working out of two different cafes recently and went to visit my site: The first cafe did not permit the Telerik CDN, while the second one does not allow the Microsoft CDN as a URL request. I can actually see the status bar in IE shows "ajax.microsoft.com" as the file being retrieved as I am waiting for the website to load.
Lack of CDN access seems to be a very unusual problem. In fact, I cannot fathom why such URL requests would be blocked when the cafe seems to permit pretty much everything else. Any reason? Could this be an availability issue at the respective CDNs themselves (ie how reliable are these CDNs)? And of-course, is there a recommended fix, apart from discarding CDN use?
Update: I can now connect to my app. So my lack of access to ajax.microsoft.com was most likely a temporary lack of MS CDN availability, and not any domain blocking.
all you need to do is implement fallback to your local server, explained here, http://happyworm.com/blog/2010/01/28/a-simple-and-robust-cdn-failover-for-jquery-14-in-one-line/
The Telerik online demos use the CDN by default, but fallback to embedded resources if the Amazon cloud service is unavailable. If you have the RadControls for ASP.NET AJAX installed locally, then you can see the source of the demo site. The files that you need to review are ~/Common/Footer.ascx and its code file ~/App_Code/QuickStart/Footer.cs, also
~/App_Code/QuickStart/QsfCdnConfigurator.cs ~/App_Code/QuickStart/HeadTag.cs. The Footer files set a cookie using JavaScript, depending on whether the CDN is available and the last two files provide support for reading the cookie on the server side and setting the appropriate configuration for the script manager.
I'm using TypeKit to provide fonts for a site I'm developing. When the page is loading it loads slow (more than a second). Turns out that this is because it's downloading the fonts on every requests. It's beyond me that a service such as this doesn't have etags configured to get clients to cache the fonts...but I digress. Until TypeKit fixes this I host the CSS locally temporarily.
Anyone had this issue with TypeKit? How did you work around it? Perhaps I'm wrong?
According to a posting on their getsatisfaction.com account, they have at least some caching in place:
One thing to note is that although the fonts are served with an Expires header, they're also served with an Etag. The browser is required to make a request after 5 minutes, but will normally use the Etag to generate a 304 (Not Modified) response - meaning, the fonts aren't actually downloaded again.
can you check what happens using Firebug?