Sales
0161 215 3814
0800 953 0642
Support
0800 230 0032
0161 215 3711

Testing Webcelerators, You Say?

In the latest post in the Webcelerator series, we take a look at the importance of testing your web accelerator to make the most of it. Test, test and test some more.

Introducing a cache into your infrastructure can cause some fairly strange problems that might not be apparent when you’re connecting directly to the webserver. Sessions may be lost, shopping carts may go missing, PayPal might not enjoy those long walks on the beach anymore. There’s very little we can’t fix or workaround, but first we need to find the issues, identify the root cause and apply the fix. While we tend to ship a fairly compatible configuration by default, every website is different. It can take some time to fix the issues you may encounter, so allow time in your Webcelerator migration plan for extensive testing before you decide to take your site live.

If you’re running an ecommerce site, you should start by going through a typical shopping session. Add items to your cart, different sizes/quantities, check you can view your cart page, that it’s still there when you go to checkout, that your 3rd-party payment processor is happy with everything, etc. Go through the steps that one of your visitors might take around your site. At the same time, check your site’s backend works without issues as well (some people prefer to leave their admin sections uncached).

By default our Webcelerators are configured to pass through SSL connections unaltered. SSL connections are not altered in any way by default, thus they receive no benefit from caching and no header alterations. This can mean that you lose sessions when switching from HTTP to HTTPS (for example, going through checkout). It also means that if most of your site is served over HTTPs, you receive no benefit from caching. There is a solution though!

SSL Offloading

By moving your SSL certificates from your webserver to the Webcelerator, we can decrypt the SSL traffic on the Webcel, send it through the cache and onto the backend, then re-encrypt the traffic to go back to the client. This has the added benefit of reducing CPU load on the webserver, as all the SSL processing is terminated at the Webcelerator.

Offloading also reduces the number of IPs required – ignoring SNI and multi-domain SSLs for a moment, the general rule of thumb is “one IP per SSL”. With SSL passthrough, you need two IPs per SSL – one on the Webcel and one on the backend. Therefore if you had four sites using SSL passthrough, you would need eight IP addresses. With offloading, this would be reduced to five IPs – one on the backend webserver and four on the Webcel. This is better for everyone involved since the world is running out of IPv4 addresses!

(As an aside, we are offering native IPv6 connectivity now. Please speak with your account manager about getting hooked up. You can run IPv4 and IPv6 on the same server and we’ll even throw in 18,446,744,073,709,551,616 IPv6 addresses for you to get started!)

In the vast majority of cases, offloading is what you want. It does mean potential code alterations, however.

Lets say you have a page – example.com/checkout – that should always be served over HTTPS. What you might normally do is check to see that the protocol used to request that page is HTTPS, and if not, redirect to the HTTPS version of the page. You might do this using a rewrite rule in a .htaccess file for Apache, for example. In PHP, this could look something like the following (disclaimer: I’m not a PHP guy and this will only work under mod_php I believe):

    if(!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == ""){
       $redirect = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
       header("Location: $redirect");
    }

With SSL offloading enabled, all traffic to the webservers from the Webcelerator comes over HTTP, regardless of the original protocol. Because of this, the above code would cause your site to enter a redirect loop:

https://example.com/checkout -> SSL offloader decrypts -> Requests page from backend via HTTP -> PHP code checks for HTTPS -> Nope, redirect to https://example.com/checkout -> repeat

The solution for this is to change your code so that it checks for the X-Forwarded-Proto header instead and redirects based on the result of that. The Webcelerator will set the X-Forwarded-Proto header to ‘https’ if the original request came in via HTTPS. If the original request came in via HTTP, the header will not be present.

    if ( !isset($_SERVER['HTTP_X_FORWARDED_PROTO']) || !strtolower($_SERVER['HTTP_X_FORWARDED-PROTO']) == 'https') {
      $redirect = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
      header("Location: $redirect");
    }

You can always wrap this into your existing SSL check functions so your site can continue uninterrupted while you prepare to move behind the Webcelerator for real. An example is here:

http://wordpress.org/support/topic/request-modify-is_ssl-function-to-check-for-http_x_forwarded_proto

We can support both SSL passthrough and SSL offloading on the same Webcelerator, however you have to do this on different VIPs.

SSL Offloading Example UKFast Webcelerator

Share with:

Enjoy this article?