Pantheon supports setting a NO_CACHE cookie for users who should bypass the cache. When this cookie is present, Varnish will neither get the user's response from any existing cache or store the response from the user into the cache.
This allows users to immediately see comments or changes they've made, even if they're not logged in. To best achieve this, we recommend setting the NO_CACHE cookie to exist slightly longer than the site's page cache. This setting allows content contributors to resume using the cached pages once all cached pages have been updated.
Ignoring GET Parameters
For the purpose of optimizing cache hits for identical content, Varnish ignores any GET parameter prefixed with __ (two underscores) or utm_ in determining the cache key. This optimization is compatible with services such as Google Analytics and AdWords that use these query parameters solely for tracking and do not alter the page content returned by the application server. The double-underscore prefix for parameter keys and cookie names is a standard convention used by front-end code to indicate a value that can be safely ignored on the back-end.
For example, ?__dynamic_id=1234 is ignored, while ?dynamic_id=1234 and ?_dynamic_id are considered distinct pages.
The query parameters are still passed to the application server, however the values are replaced with PANTHEON_STRIPPEDto indicate that cache optimization is in effect for this parameter. Avoid using these parameters in ways that alter content in the response.
For more information, see PANTHEON_STRIPPED GET Parameter Values.
External Authentication (e.g. Facebook login)
If your site or application requires Facebook authentication, we have added exceptions for this to allow users to register and log in. In the event you are having problems with another external authentication service, please contact us and let us know what service you are having issues with.
Using Your Own Session-Style Cookies
Pantheon passes all cookies beginning with SESS that are followed by numbers and lowercase characters back to the application. When at least one of these cookies is present, Varnish will not try to respond to the request from its cache or store the response.
Drupal Sites
Drupal uses SESS-prefixed cookies for its own session tracking, so be sure to name yours differently if you choose to use one. Generally, SESS followed by a few words will work.
Correct: SESSmysessioncookie, SESShello123, SESSletsgo
Incorrect: SESS_hello, SESS-12345, mycustomSESS, Sessone, sess123testing, SESSFIVE
WordPress Sites
WordPress does not use PHP session cookies; however, some themes and plugins do. If you are using a theme or plugin that requires PHP sessions, you can install Pantheon-sessions. It is designed to handle the naming properly.
Geolocation, Referral Tracking, Content Customization, and Cache Segmentation
A site may need to deliver different content to different users without them logging in or starting a full session (either of which will cause them to bypass the page cache entirely). Pantheon recommends doing this on the client side using browser detection, orientation, or features like aspect ratio using HTML5, CSS3, and JavaScript. Advanced developers can also use STYXKEY.
Using Modernizr
Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user's browser. This will also allow requests to have the benefit of being saved in Varnish and rendering correctly, depending on the requirements. Modernizr is available as a Drupal module or a WordPress plugin.
Device Detection
We do not recommend building separate mobile sites or using cookies that are passed to the backend for mobile theme detection and configuration. This will cause issues scaling requests within your site in case of any load or traffic spikes, as it requires at least the initial hit to make it to the backend before anonymous traffic can be cached by Varnish. If you receive more uncached visitors than your Nginx and PHP processes, it can result in timeouts and server errors.
Best Practice Recommendations
We recommend handling mobile detection using Responsive Web Design (RWD) techniques with HTML5, CSS3, and JavaScript. This will avoid the need to compromise potential scalability in order to scale traffic. HTML5 and CSS3 is the high performance route, as you save on the backend load and browsers.
Issue Implementing the mobile site on a different domain, subdomain, or subdirectory from the desktop site.
Recommended Solution
While Google supports multiple mobile site configurations, creating separate mobile URLs greatly increases the amount of work required to maintain and update your site and introduces possible technical problems. You can simplify things significantly by using responsive web design and serving desktop and mobile on the same URL. Responsive web design is Google’s recommended configuration.
More information on mobile site best practices can be found in the Google official developer documentation:
https://developers.google.com/webmasters/mobile-sites/get-started/why https://developers.google.com/webmasters/mobile-sites/get-started/key https://developers.google.com/webmasters/mobile-sites/get-started/mistakes
A full list of the devices and their support for HTML5 is available on https://html5test.com:
Varnish Servers
Pantheon uses a rotating pool of Varnish servers. Varnish does not have a shared pool or cache, so that means there is a distinct cache for each server. While local DNS typically picks a route and keeps using it, it is possible to access a different Varnish server and experience a cache miss.
The Max-Age returned in the header may vary depending on which cache server is hit. The main concern when examining Age is whether or not it is increasing, as this indicates that Varnish is indeed working.
Varnish, Public Files, and Cookies
Pantheon strips cookies from requests made to public files served from sites/default/files, which allows Varnish to cache the response.
HTTPS & Varnish
When a Pantheon environment is configured with HTTPS, a dedicated IP address to a load balancer is provided. Connections via HTTPS to the load balancer are decrypted by an HTTPS or TLS termination server using the client’s uploaded certificate, then handled like any other request, including the same rules for Varnish caching. The result is encrypted by the SSL termination server and served back to the client, completing the request.
404s & Varnish
Pantheon’s default is to not cache 404s, but if your application sets Cache-Control:max-age headers, Varnish will respect them. Depending on your use case, that may be the desired result.
Drupal Sites
Drupal’s 404_fast_* configuration does not set caching headers. Some contributed 404 modules include cache-friendly headers, which will cause a 404 response to be cached.