If you have an AWS VPC with public and private subnets, it’s important to remember to select the public subnets when creating an Elastic Load Balancer. When the public subnets are chosen, replies from instances behind the load balancer are returned through the load balancer. If you instead select the private subnets then reply traffic is routed via the routing table for the private subnet. This results in asymmetric routing which can create a range of problems.
A resource makes a cross-origin HTTP request when it requests a resource from a different domain than the one from which it was served. For example, an HTML page served from http://acme.com makes an <img> src request for http://mydomain.com/image.jpg. Many pages on the web today load resources like CSS stylesheets, images and scripts from separate domains.
For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. The solution to allowing cross-origin requets is the new Cross-Origin Resource Sharing (CORS) mechanism.
If http://acme.com makes a scripted request for http://mydomain.com/image.jpg then the server hosting mydomain.com must include an “Access-Control-Allow-Origin” header. This header signals to the browser that it is ok to use the resource. The value of the header can be “*” which allows requests from all domains or it can be the name of an individual domain like “acme.com”.
If you’re using WordPress with the W3 Total Cache plugin to host static content on RackSpace Cloud Files, then you may need to add the Access-Control-Allow-Origin header to the object in Cloud Files. Let’s take an example … maybe your theme use a font at:
After you’ve activated the CDN features in W3TC, you may notice that myfont.woff is not loading and you’ll see an error in the console log in your browser indicating the cross-origin problem. The solution is to:
a. Login to mycloud.rackspace.com
b. Go to Storage -> Cloud Files and drill down to the file in question
c. Click the gear icon next to the files and select “Headers”
d. Add the “Access-Control-Allow-Origin” header with a value of “*”.
e. Wait a little while for the change to propagate.
Now your font should load without problems.
We get frequent questions from WordPress clients with W3 Total Cache (W3TC) and RackSpace Cloud Files (RCF) content distribution network (CDN) about how to make changes to the website visible.
First some general notes:
- Content changes or updates to pages or posts do not involve the CDN so no special actions are required. W3TC will automatically flush old pages and post revisions from it’s caches.
- Media files uploaded through WordPress admin will be automatically uploaded to the CDN and can be immediately used in post or pages with no additional action.
As an example, let’s assume that you’ve modified you themes primary stylesheet at:
You made the modification by downloading the file, editing on your workstation and then uploading via SFTP back to the server. In this case W3TC has no way of knowing that you’ve made a change to the file so it does not know that the file needs to be uploaded to the CDN.
First you’ll need to sync or upload the file to the CDN:
- Login to WordPress admin.
- Go to Performance -> CDN
- Click the appropriate upload button in the General section. The button will depend on what type of file you’ve changed. In this example we need to click the “Upload theme files” button.
- A popup window will open when you click the button similar to this: In the popup window, click the “Start” button. The sync process will start and you’ll be able to see as each file is examined. If the file has not changed since the last sync the it will be marked “Object up-to-date”. If the file is now or has changed then it will be marked with “Ok”.
- After the sync process completes you can close the popup window. If you have many files it may take several minutes to several hours to fully sync.
Now the new or changed file has been uploaded to the CDN. If it’s a new file then it will be immediately available for use in your site. If instead you are changing a file then we have to take an additional step and “purge” the file from the CDN.
CDN’s function by distribution content to access points close to the user. For large CDN’s there might be dozens or even hundreds of access points. When a user requests a file, the request is routed to the closest access point. The CDN infrequently check back with your web server for changed or updated files. The frequency of these checks is call the “Time to Live” or TTL. By default RCF sets a 24 hour TTL on all files. So after uploading a change, it may take up to 24 hours before the change if visible on on access points. This can be a problem for our CSS change as users on different access point might get different versions of the file.
W3TC includes a “purge” feature which you can use as follows:
- Login to WordPress admin
- Go to Performance -> CDN
- Look for the Purge button above the General section. Click the Purge button to open the CDN Purge Tool popup window.
- Enter the relative paths of each file that you want to purge into the “Files to purge” field.
- Click the Purge button and wait for the process to complete.
- Close the CDN Purge Tool window.
Purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request but this is still much faster then the 24 hour TTL.
We have had mixed success with the W3TC CDN Purge Tool. If I need a change purged as fast as possible then I prefer to run the purge from the RackSpace Cloud Files control panel as follows:
- Login to https://mycloud.rackspace.com
- Go to Storage -> Files
- Drill down on your container and then to the file that you want to purge.
- Click on the Gear icon next to the file to open the drop down menu.
- Select “Refresh File (Purge)” from the menu. A small confirmation dialog will open.
- Click “Purge File” button in the dialog to complete the process.
Again purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request.
Is there anyway to make updates to the CDN faster?
Short answer is “no”. The TTL and propagation delay is the nature of the CDN. Generally the benefits of distributing content win out over the update delays.
But two notes:
- New files do not experience any propagation delay. If you want to change a file and have it propagate instantly then change the name of the file so it is seen as a new file by the CDN.
- You can lower the TTL of the CDN container. If you have a big setup of updates planned, then it might be a good idea to lower the TTL a few days in advance so that you minimize propagation delay.
If you try to serve fonts from RackSpace Cloud Files or other CDN then you may run into problems with browsers refusing to load the fonts. Here’s an example error:
Font from origin ‘http://xxxxx.xxx.rackcdn.com’ has been blocked from loading by Cross-Origin Resource Sharing policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://www.acme.com’ is therefore not allowed access.
The problem is your browser doesn’t consider it secure to load the font from a different domain then the web page itself was loaded from.
The solution is CORS or Cross-Origin Resource Sharing as described here:
When RackSpace Cloud Files serves the font file, it needs to set a header like:
or more specifically:
This informs your browser that it is save to include this resource in the indicated alternate origin.
RackSpace Cloud Files provide a means to change the headers on individual files. Here’s the technical details:
You can also set headers from the mycloud.rackspace.com portal. Just login, go to Storage -> Cloud Files and locate your font file. Click the gear icon and choose Edit Headers. A dialog will open where you can set the “Access-Control-Allow-Origin” header.
Note that it takes some time for header changes to propagate through the CDN. I always purge the file after making changes in the hopes that this will accelerate propagation but I can’t confirm that it helps.
With the addition of CORS headers you can reliably service your font files from the CDN!
turbolift is an absolutely brilliant utility for manipulating RackSpace Cloud Files. With turbolift you can do things like:
- Upload a directory, (recursively)
- Upload a single file
- Upload a local directory (recursively) and sync it with a Cloud Files Container
- Download a Container to a local directory
- Download changed objects from a Container to a local directory
- Compresses a Local Directory, then uploads it
- List all Containers
- List all Objects in a Container
- Delete an Object in a Container
- Delete an entire Container
- Clone one Container in one region to another Container in the same or Different Region.
- Set Custom headers on Objects/Containers
So in this article I’m going to demonstrate how to clone a container.
Here’s the download link for turbolift:
On CentOS 6.5 the install is easy:
yum install python-devel python-setuptools
git clone git://github.com/cloudnull/turbolift.git
python setup.py install
Now lets assume that we have a container on RackSpace Cloud Files name “devimages” and we want to copy or clone the contents of that container to another container named “prodimages”. Here’s the turbolift command:
turbolift -u [USERNAME] \
-a [APIKEY] \
--os-rax-auth [SOURCE REGION] \
-sc devimages \
-tc prodimages \
-tr [DESTINATION REGION]
The [SOURCE REGION] and [DESTINATION REGION] should be one of ‘dfw’, ‘ord’, ‘iad’, ‘lon’, ‘syd’ or ‘hkg’.
turbolift is fast – it takes about 10 minutes to clone a 2GB container with 18K objects in the same region.