Many web analytics software packages enable you to
measure traffic by adding unique HTTP query string parameters to URLs. By
modifying a base URL (such as https://www.example.com/path/to/page) and
adding query string parameters, you can measure user behavior and engagement.
For example, the following URL contains two common query string parameters
(utm_medium and utm_source) appended to the base URL:
https://www.example.com/path/to/page?utm_medium=notification&utm_source=email
On Cloud Platform, Varnish® strips the query strings from popular web analytics software packages and then stores a cached version of the page according to the base URL, instead of the full URL with appended query strings, without breaking the reporting to your web analytics software. Cloud Platform will serve the version of the page stored in Varnish cache for subsequent requests that match the base URL, varying only by the query string parameters, which enables measurable marketing campaigns while preserving website performance.
For example, Cloud Platform will display each of the following webpages as the
same cached webpage (https://www.example.com/path/to/page) to a visitor:
https://www.example.com/path/to/page?utm_medium=notificationhttps://www.example.com/path/to/page?_ga=1.000001https://www.example.com/path/to/page?utm_medium=notification&utm_source=emailhttps://www.example.com/path/to/page?utm_medium=notification&utm_source=facebook
When serving a webpage to a visitor, Varnish performs the following steps:
Strip the query string parameters from the requested URL.
Add an
X-Acquia-Stripped-Queryheader that contains the query string parameters to the HTTP request.Redirect the request to both the non-bare and
https://prefixed version of the domain.If permitted by caching policy, cache the returned webpage according to the base URL.
Serve the content to the visitor.
Note
Acquia recommends using both the non-bare and https:// prefixed version
of your domain to prevent unnecessary redirects, reducing load on your
subscription’s infrastructure.
Varying cache by stripped queries
To vary cache by stripped queries, use the HTTP Cache Control module. This module
allows you to add X-Acquia-Stripped-Query to the Vary header and hence,
varies the caching of their responses by the stripped queries as if the queries
were never stripped in the first place. If you follow this mechanism, you don’t
need to create a custom Drupal module.
Note
If you use the HTTP Cache Control module, the caching effectiveness on heavily stripped pages is disabled. However, this module allows cache to vary, based on the above parameters, if the Drupal site uses them in this way.
Alternatively, if the X-Acquia-Stripped-Query header is present on webpages
that shouldn’t be cached, you can create a custom Drupal module to add the
following header to the responses to prevent caching:
Cache-Control: must-revalidate, no-cache, private
For tools to inspect the HTTP response headers of a webpage, see browser developer tools. For methods of controlling caching for certain types of responses, see Set max-age headers for specific pages, files, or paths.
Important
Use caution when removing caching from responses, as doing so can have negative performance implications.
Using the X-Acquia-Stripped-Query response header in Drupal
For uncacheable requests where the contents of X-Acquia-Stripped-Query can
be used by parsing the $_ENV['HTTP_X_ACQUIA_STRIPPED_QUERY'] variable with
the following Drupal functions:
Drupal version | Function |
|---|---|
Drupal 7 | |
|
Note
This method does not populate the response or request headers.