Suggestions for How to Test Fastly

We're often asked "how should I test Fastly before making it live for my customers"? Here are a couple of "Fastly defaults" to remember (or learn), and a simple list of situations that may be applicable for your site. These are just to start with-- you of course know your business rules and the way your site operates better than we could guess.

• What are your default Surrogate-Control / Cache-Control / Expires headers? Are these different for different content types? Fastly will honor those rules in that order to determine a TTL for your cached asset.  
• For responses lacking Surrogate-Control / Cache-Control / Expires headers, should CDN cache for a default TTL, or simply not cache? By default we WILL CACHE many assets depending on the Status Code 
• Do you take query parameters into account when caching? If not is it OK to strip them out when generating cache key? Fastly includes query parameters in the cache key by default.
• We will not cache an asset that comes from your origin with a Set-Cookie header, or with Cache-Control: private. We DO cache assets with Cache-Control: no-store or Cache-Control: no-cache. We consider these to be browser directives.
• Do you have many 404s as normal part of your site behavior? We cache these by default.
• Do you need to support older browsers? By default our certificates disable TLS below 1.2 and any 3DES encryption. Certain older browsers /clients won't be supported by default. If you can, please test from one of these to ensure acceptable degradation of experience.
• Most of our TLS certificates use SNI. Some older clients cannot support SNI. Do you have any of these clients accessing your site? Consider any APIs you may have and what scripts are accessing those-- if these are third parties you may need a setup that does not include SNI.

When you have your service set up the way you like, now it's time to access your site through Fastly (most commonly with an /etc/host override as described in our docs). Here are just a few things you should test:

• Log in / Log out: make sure assets that are appropriate for a logged in user are not caching if that is correct.
• Log in with a different userid. Are you seeing the correct user logged in?
• Updating a shopping cart-- make sure these are not caching.
• Make a purchase as guest vs logged in.
• Purchase with different payment types
• Test a 404 URL: shorten the TTL for these if desired-- Fastly will cache these by default.
• confirm the 404 isn't setting a user defining session cookie or otherwise behaving differently when logged in and/or has items in cart
• Test a 500 triggered from origin-- confirm this is not cached
• Confirm that 404 / 500 responses aren't behaving differently when logged in and/or you have items in cart
• Try these links & steps from multiple browsers across multiple client types-- laptop (Chrome, Firefox), mobile (Android, iOS)
• Confirm Surrogate Key setting and purging is working-- set a "Fastly-Debug:1" header to see those keys
• Confirm that whitelist ACLs are working correctly
• Test Backend origin failures-- particularly if you've enabled serve stale.
• Test backend/failover recovery as well as failover triggering.
• Trigger a healthcheck failure and confirm serving stale or other failover.
• If you've changed the default behavior of the Vary header or the cache key, confirm that these are working as intended. Also test a purge against these assets.
• Access some URLs with both HTTPS and HTTP: make sure redirects happen if you've set those up. Ensure it fails gracefully.
• If you have an EV cert hosted on Fastly, confirm that's displaying properly.
• Confirm your log stream / log rotation is working as intended. Some of our logging endpoints work in batch-- you will not get data until the batch timeframe has passed.
• A few hours/days before cutover, reduce DNS TTL to less than 10min so that you can quickly cut away from Fastly in case of any issues. The exact time prior depends on your current DNS TTL.