This article will show you some mod_rewrite wizardry to get your static content served from your own “cdn” domain until CNAME support is here.
Requirements
This article assumes you know how to get the public URL for your container, and are familiar with uploading files to the Rackspace Cloud platform.
All implementations require an Apache web hosting account with mod_rewrite enabled.
You may use either a subdomain (eg: cdn.domain.com) or a subdirectory (eg: www.domain.com/cdn) to implement this. I recommend using a subdomain.
Implementation #1
This implementation is the simplest approach and simply redirects all users to the CDN. You are limited to one bucket with this approach.
In the base directory of your subdomain you will need to create a ‘.htaccess’ file that looks like the following:
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/$
RewriteRule ^(.*)$ http://c0918182.cdn.cloudfiles.rackspacecloud.com/$1 [R=302,L]
You will need to replace ‘c0918182’ with the ID of your container.
The rewrite condition will not redirect requests for / to Cloud Files. This allows you to create an index file. We’re using a 302 temporary redirect (instead of 301 permanent) so search engines will pick up the URLs under your custom subdomain (and not the Cloud Files URL).
Implementation #2
This implementation is similar to implementation #1, except it allows you to have multiple containers so you can segregate your content. For example, this will allow you to have http://cdn.domain.com/images/ and http://cdn.domain.com/files/ going to two different Rackspace Cloud containers.
We’re going to use ‘images’ as our first example.
To get started, create the directory in your subdomain.
In this directory, create a ‘.htaccess’ file that looks like the following:
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/images/$
RewriteRule ^(.*)$ http://c0918182.cdn.cloudfiles.rackspacecloud.com/$1 [R=302,L]
You will need to replace “/images/“ with the name of your directory, and replace ‘c0918182’ with the ID of your container.
Like implementation #1, the rewrite condition will allow you to create an index file in your directory.
To link additional directories to different containers, simply repeat the instructions with a different directory name and container ID.
Nginx Implementation
If you’re running Nginx, you can accomplish the same effect using locations and rewrites. This will be similar to implementation 2 for Apache. Any file that does not exist in the file (such as an index file, or some arbitrary file you felt like putting there) will be served off of the CDN.
In your Nginx config, you’ll create a new server directive for your subdomain as well the location block for your redirects.
server {
listen 80;
server_name cdn.failverse.com;
access_log /var/log/nginx/cdn.failverse.access.log;
location / {
root /var/www/vhosts/domain2/public/cdn;
index index.html;
if (!-e $request_filename)
{
rewrite ^/images/(.*)$ http://c0918182.cdn.cloudfiles.rackspacecloud.com/$1 redirect;
rewrite ^/files/(.*)$ http://c0918176.cdn.cloudfiles.rackspacecloud.com/$1 redirect;
}
}
}
You will need to replace /files/ or /images/ with the relevant directory and ‘c0918176’ with the container name. You are able to create as many redirects this way as you want.
Lighttpd
If you use Lighthttpd, you can use the following configuration to accomplish the same thing.
$HTTP["host"] == "cdn.failverse.com" {
url.redirect = ( "^/images/(.*)" => "http://c0918182.cdn2.cloudfiles.rackspacecloud.com/$1",
"^/text/(.*)" => "http://c0918182.cdn2.cloudfiles.rackspacecloud.com/$1")
}
Original Credit however the domain is down, and the article is a bit outdated.
This is awesome. What about billing? We’re not going to get charged for the bandwidth between the web server and the Cloud Files?
There isn’t any billing on the server, just your CDN bandwidth. The server just tells the browser to pull the file from cloud files, it’s not as awesome as a CNAME (they can see the redirects and such) but it’s better then nothing until CNAME support is implemented.
There will be a small amount of inbound bandwidth to the Cloud Server, when it receives the request line and headers (usually somewhere around 500 bytes per request), but as Ryuujinx said, the actual data is being downloaded directly from the CDN, not passing through the Cloud Server.
How can i make the .htaccess file rewrite all the subdirectories to the root of CDN ?
for example:
rewrite “http://sub.main.be/files/css/mystyle.css” (or /images/thumbs/ or whatever)
to “http://c0918182.cdn.cloudfiles.rackspacecloud.com/mystyle.css”
Ah, Jan had my same question, as we can’t have subdirectories in our CDN containers, but might like to have any reference to a subdirectory on our subdomain to point to the CDN container.
Cheers!
This should do what you’re looking for –
It will redirect any subdirectories deep to http://c0918182.cdn.cloudfiles.rackspacecloud.com/file.ext
As always replace the CDN url with your own container’s.
As for subdirectories, you can have “Fake” subdirectories, the more common file managers support this (See Cyberduck on OSX and Fireuploader if you’re a firefox extension. There’s also a windows manager called Cloud Files manager that’s paid use)
Edit: You don’t technically need the RewriteCond directive as all requests to the directory and any subdirectories are being redirected to the CDN url.
I have this in the files folder (from the official WIki) and all the stuff it doesn’t find on the app server it grabs from Cloud Files.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ http://c1304952.cdn.cloudfiles.rackspacecloud.com/$1
Problem is Google is not indexing any of my site’s images that are server in this way from the Cloud Files.
For example this page:
http://www.zibo.ro/planeta-foto/v/Iacob-Rares-Stefan-Zibo-3211
comes first in google search for the kid’s name “Iacob Rares Stefan”.
The main image and all the thumbnails are served with a “302 Found” and none of these come up in Google Image search.
Right now I’m out of ideas. The naming of the files is not SEO friendly but still that can’t be the sole cause for the problem…
Why cant I simple create a CNAME for that?
@Marucio: CNAME support did not exist at the time of this article, and still isn’t released yet.