Set far-future expires headers with Rackspace Cloud Files (sort of)

To keep parity with existing relationships, a client has required that we work with Cloud Files instead of Amazon’s CloudFront. There seems to be quite a bit of confusion about which offering actually performs better, but from my perspective, the Amazon API is much more intuitive, and therefore easier to work with. That said, there seems to be a lot of misinformation out there about Cloud Files; after spending a day with the API, I am pleased to conclude that the API is not as bad as I had initially thought. Rackspace could likely benefit from a little platform evangelism…

The biggest issue I’ve seen reported from a number of sources is the 72 hour TTL limit via the Rackspace control panel. Cloud Files uses TTL as an expires header of sorts. So I jumped on support chat, and quickly learned that the 72 hour TTL is only a limitation of the control panel, and a far-future TTL can easily be set via the API.

For this particular project, I’m using CakePHP, so don’t get too caught up on that App::import static method. Assuming cloudfiles.php, cloudfiles_exceptions.php, and cloudfiles_http.php are all in a cloudfiles folder in the vendors directory…

function publish(){
    //load up the cloudfiles class
    App::import('Vendor', 'cloudfiles/cloudfiles');

    //create a connection with your Cloud Files username and API secret
    $auth = new CF_Authentication('USER_NAME', 'API_SECRET');
    $conn = new CF_Connection($auth);

    //grab an instance of our container
    $container = $conn->get_container('CONTAINER_NAME');

    //get the container's current TTL (assuming this was an existing container)
    debug( $container->cdn_ttl );

    //now just call the make_public method with a TTL parameter
    //here I'm just setting it to 30 days
    $container->make_public(86400 * 30);

    //confirm the TTL was properly updated
    debug( $container->cdn_ttl );

The script outputs TTL values of 259200 and 2592000 respectively; the TTL on the container is now 30 days instead of 3. I have not noticed the updated TTL on the Rackspace control panel yet, but I’ll update this post if it is accurate once the existing 72 hour TTL expires.


  1. sam says:

    Great post! I can confirm this works as described. It seems to take an unspecified amount of time to become active on the CDN (10 mins or so) but works perfectly. Thanks

  2. alan blount says:

    I am about to implement a RSC Files API as a CakePHP datasource/lib and potentially extend the PHP bindings from RSC… I was wondering if you have already done this and shared it anywhere…

  3. Billy Bob says:

    AWESOME! Thanks a lot. Works like a charm! TTL on CloudFiles is now longer!

  4. khaleel says:

    Does this mean that after 30 days the file will be deleted? I want to delete a file after 30 days?

    • kettle says:

      Hi Khaleel,

      No, this does not mean the file will be deleted after 30 days; to delete the file, I would write a shell script and execute via cron to make an API request to delete the file. Instead this will send a 30-day expires header along with the requested file so that your browser knows to keep the file cached for that period of time.

  5. Gordon Jaywood says:

    Awesome write up, I needed this for a client since he wants different containers having different TTL’s setable within their back end, if anyone doesn’t want to use PHP or C programming to set the TTL’s they can always opt to use the SSH and CURL method using their Rackspace Cloud Server, I found which explains a bit but I wish Rackspace would have better documentation for people like me since I need so much more help :P


Leave a Reply to kettle