Alexa metrics
Live Chat

Welcome to UKFast, do you have a question? Our hosting experts have the answers.

Chat Now
Sarah UKFast | Account Manager

BacktoBasics: Your Webcelerator Part 4

11 March 2013 by Boba

In the latest of our Webcelerator posts we’re looking at cookies, cache control and purging as we delve into deeper into making the most of your web acceleration technology.

Cookie Monster

cookies webceleratorCookies are the enemy of caching.

By setting a cookie, you’re essentially telling the cache “this is dynamic content, don’t cache me”. In itself, this is fine – we don’t want to cache everything, certainly not truly dynamic content.

Above, I stated that we forcibly cache certain static filetypes by default, and to do this we strip the Set-Cookie and Cookie headers from the requests going back and forth. This is generally to work around misbehaving sites that set cookies with everything they send to the client (certain ASP.NET applications, I’m looking at you!). These cookies aren’t necessary and will stop the Webcelerator from caching the content, reducing the effectiveness (and therefore the ROI) of the Webcelerator.

If you have other static content than the filetypes listed above, and you want these cached automatically by the Webcelerator, please ensure that you aren’t sending cookies with the content (static HTML files, for example). You should set an appropriate Cache-Control header at the same time to ensure the content is cached for as long as you want it to be!

Cache-Control to Major Tom

Section 14.9 of RFC 2616 describes the Cache-Control header in full.

Using the Cache-Control HTTP header, you have control over what is and what is not cached by the Webcelerator (minus the file types described above in the default configuration). You should add an appropriate Cache-Control header to the response that you send back to the client, and the Webcelerator will interpret this and obey your request in most cases!

I won’t go into Cache-Control header settings too much here as it’s a subject to itself! The link above should provide you with all the information you need. The Webcel will obey your Cache-Control settings apart from the file types specified above (by default).


Sometimes you’ll need to roll out a critical update to your site, changing some images and CSS, but the cache has another 2 hours before it’ll request the content from the backend server again. What do you do?

You can clear items from the Webcelerator cache by making a HTTP PURGE request to the Webcelerator with the URL of the item you wish to purge. This item will be immediately removed from the cache, and the next time it’s requested, it will be pulled directly from the backend webserver.

An example PURGE request:

   PURGE /images/logo.png HTTP/1.0

(Yep, that’s a Host header with a HTTP/1.0 request!)

If you made the above request to your Webcelerator, you would receive a 200 OK status if the purge was successful.

Purges are restricted – only requests from certain IP addresses are allowed. By default, this should include the webservers that the Webcelerator is pointing at. If you wish to be able to purge from other IP addresses, please let the support team know and we can add these in for you.

There are several ways to go about purging objects from the cache. If you only need to purge a few items on an occasional basis, you should be okay to do this manually. You can do this with telnet for that old school feel:

    # telnet 80
    Connected to (
    Escape character is '^]'.
    PURGE /images/logo.png HTTP/1.0
    HTTP/1.1 200 Purged.
    Accept-Ranges: bytes
    Date: Wed, 17 Oct 2012 09:00:47 GMT
    Age: 0
    Connection: close
    X-Cache: MISS
    Server: WebCelerate
    Via: WebCelerate

Slightly easier and more scriptable is the use of curl. The following command does the same as the above. (For clarity, that’s a capital ‘i’ and a zero):

    curl -I0 -X PURGE -H “Host:”

Again, this would return a 200 OK if the purge was successful.

The best method for clearing the cache is going to be programmatically, however. An example of performing a purge in PHP follows – note that you will need the ‘pecl_http’ module installing (on Linux boxes this can be done with the command `pecl install pecl_http`). Adjust $DomainName, $VIP and the $request as desired:

        $DomainName = "";
        $VIP = "";
        $request = new HttpRequest("http://$VIP/images/logo.png", HttpRequest::METH_PURGE);
        $request->setHeaders(array('Host' => "$DomainName"));
        try {
            if ($request->getResponseCode() == 200) {
                echo "Success!!";
         } catch (HttpException $exception) {
            echo $exception;

Is there an easy way to purge content from my cache?

There is a new purge option in the MyUKFast client area that you can use to purge your Webcelerator cache when you wish. You’ll find a Webcelerator link under the Products and Services menu – clicking that will take you to a form where you can specify the domain you wish to purge.

If you have Webcelerators but are unable to see the link, or you receive an error when attempting to use the form, it’s likely that we need to perform some quick additional configuration on your Webcelerator. Please raise a ticket and we’ll enable this for you!

Once you have access to the form, you can enter a list of domains and/or paths that you wish to have purged. We will always attempt to purge www-prefixed and non-www prefixed domains from the cache at the same time (as and are two different documents from the cache’s point of view). You can purge specific paths too, so if you’ve just updated your CSS, you can just purge e.g. to clear everything under /css at once.

Please be aware that all paths are matched in a case-sensitive manner.

For advanced users, this form fully supports case-sensitive PCRE regular expressions, so feel free to purge things like ‘[0-9](-thumb)?\.(jpe?g|png)’. Using too many regular expressions may affect cache performance in the short term however, so consider purging the entire path unless you have specific requirements.

What changes can be made to the configuration?

The Webcelerator is extremely flexible. I would argue that if you can think of something you want to do with it, we can make it happen.

That said, we do receive a lot of requests to configure redirections at the Webcelerator level. We would strongly recommend you do not do this at the Webcel level unless there is a very good reason for doing so. Redirections should be handled on your web servers so you can change them when you want to.