Cloud Platform uses Varnish® caching to increase an application’s perceived performance for visitors. For more information about Varnish, see Using Varnish. Using developer tools integrated with your browser, you can examine the Varnish caching headers sent with each page and item request to see how Varnish caching is working with your application.
To examine what Varnish is doing (or not doing) on one of the pages in your application, examine the values of the Varnish cache headers for the page.
Important
Varnish HTTP response headers are appended by Cloud Platform and cannot be removed. However, it might be possible to remove these headers by using a Web
To view these headers, use one of the development tools available for your web browser to view a served web page’s Varnish headers. Your installed browser may already include a set of development tools that you can use. You can also run the following command from a command prompt:
curl -sSLIXGET urlname
The following are some of the headers you should see:
Header
Description
Age
The amount of time the served item was in the cache, in seconds. If the age is zero, the item was not served from the Varnish cache.
Cache-Control
The directives that must be applied by all caching mechanisms, from Varnish to the browser cache.
If the field has the value no-cache,must-revalidate,post-check=0 or pre-check=0, this item instructs any upstream proxy layers (such as Acquia load balancers or a CDN) to not cache. This header generally is used when Drupal page caching is disabled. Acquia recommends you verify this value is present on all of your website’s pages. If it is, enable caching, and consider using Acquia Purge for cache invalidation.
Note
Setting this header does not disable caching of 301 and 404 responses. The responses are still cached by Varnish, but the application controls the cache lifetime instead of Varnish enforcing the 15-minute minimum.
For example, if a site's Drupal cache maximum age (system.performance > cache > page > max_age) is set to 60 seconds:
With X-Acquia-No-301-404-Caching-Enforcement: 1 set - a 404 response returns Cache-Control: max-age=60, public (the site's 60-second cache duration is used).
Without the header - the same 404 response returns Cache-Control: max-age=900, public (Varnish overrides to the 15-minute minimum).
How to set this header
Set this header in PHP code. For example, add the following line to your settings.php file:
On Cloud Classic, mod_headers directives in .htaccess files are not applied to PHP/Drupal requests — they only apply to static files. Because this header must be present on responses generated by PHP/Drupal, do not use .htaccess to set this header on Cloud Classic. Use PHP code instead.
On Cloud Next, mod_headers directives in .htaccess are applied to PHP/Drupal requests, so you can use either PHP code or .htaccess. For consistency across environments, using PHP code is recommended. For more information, see Known issues in Cloud Next.
Verifying the header
To confirm the header is working, use curl to request a non-existent path and check the response headers:
If the header is set correctly, you should see X-Acquia-No-301-404-Caching-Enforcement: 1 in the response headers, and the Cache-Control max-age should reflect your site's configured cache duration rather than 900 seconds.
Varnish headers
Cloud Platform uses Varnish® caching to increase an application’s perceived performance for visitors. For more information about Varnish, see Using Varnish. Using developer tools integrated with your browser, you can examine the Varnish caching headers sent with each page and item request to see how Varnish caching is working with your application.
To examine what Varnish is doing (or not doing) on one of the pages in your application, examine the values of the Varnish cache headers for the page.
Important
Varnish HTTP response headers are appended by Cloud Platform and cannot be removed. However, it might be possible to remove these headers by using a Web
To view these headers, use one of the development tools available for your web browser to view a served web page’s Varnish headers. Your installed browser may already include a set of development tools that you can use. You can also run the following command from a command prompt:
curl -sSLIXGET urlname
The following are some of the headers you should see:
Header
Description
Age
The amount of time the served item was in the cache, in seconds. If the age is zero, the item was not served from the Varnish cache.
Cache-Control
The directives that must be applied by all caching mechanisms, from Varnish to the browser cache.
If the field has the value no-cache,must-revalidate,post-check=0 or pre-check=0, this item instructs any upstream proxy layers (such as Acquia load balancers or a CDN) to not cache. This header generally is used when Drupal page caching is disabled. Acquia recommends you verify this value is present on all of your website’s pages. If it is, enable caching, and consider using Acquia Purge for cache invalidation.
Note
Setting this header does not disable caching of 301 and 404 responses. The responses are still cached by Varnish, but the application controls the cache lifetime instead of Varnish enforcing the 15-minute minimum.
For example, if a site's Drupal cache maximum age (system.performance > cache > page > max_age) is set to 60 seconds:
With X-Acquia-No-301-404-Caching-Enforcement: 1 set - a 404 response returns Cache-Control: max-age=60, public (the site's 60-second cache duration is used).
Without the header - the same 404 response returns Cache-Control: max-age=900, public (Varnish overrides to the 15-minute minimum).
How to set this header
Set this header in PHP code. For example, add the following line to your settings.php file:
On Cloud Classic, mod_headers directives in .htaccess files are not applied to PHP/Drupal requests — they only apply to static files. Because this header must be present on responses generated by PHP/Drupal, do not use .htaccess to set this header on Cloud Classic. Use PHP code instead.
On Cloud Next, mod_headers directives in .htaccess are applied to PHP/Drupal requests, so you can use either PHP code or .htaccess. For consistency across environments, using PHP code is recommended. For more information, see Known issues in Cloud Next.
Verifying the header
To confirm the header is working, use curl to request a non-existent path and check the response headers:
If the header is set correctly, you should see X-Acquia-No-301-404-Caching-Enforcement: 1 in the response headers, and the Cache-Control max-age should reflect your site's configured cache duration rather than 900 seconds.
Note
If the Cache-Control header contains both s-maxage and max-age values, Varnish uses s-maxage to determine the cache lifetime for that request.
Server
The web infrastructure application (currently nginx) that acts as a load balancer to serve the content.
Vary
The inbound HTTP request headers that need to be taken into account when caching a single URL. The most common example is Accept-Encoding – a header that browsers usually send to websites to indicate whether they want the returned page compressed using gzip or the deflate compression algorithm. This can prevent serving gzip-compressed pages from cache to older browsers that do not support it.
Via
The web infrastructure application (currently Varnish) over which the request was sent.
A response header added when a request is forwarded to PHP-FPM. If PHP-FPM was not needed to serve this request, this header is not added.
X-AH-Environment
The Acquia environment that provides the page response. Usually prod, but could also include values such as dev or stage.
X-Cache
Either HIT or MISS depending on whether or not the item was served from the Varnish cache.
X-Cache-Hits
The number of times this object has been served from cache. Higher numbers indicate that this URL has received more visitors.
X-Drupal-Cache
Similar to X-Cache, this header indicates the outcome of Drupal’s page cache with HIT or MISS values. A MISS value is not unusual here. For more information about Drupal cache MISS, see Varnish cache HITS and Drupal cache MISS.
X-Forwarded-For
The originating IP address for a request.
X-Generator
The software used to create the page. On Cloud Platform, this says Drupal along with the version number of Drupal core.
X-Geo-Country
The two-letter ISO-3166–1 alpha-2 country code. Available only for Cloud Platform Enterprise and Site Factory subscriptions with dedicated load balancers. For more information, see Using GeoIP information.
Certain non-HTML static assets have cookie headers removed, and receive the HTTP request header X-Static-Asset:True. For more information, see Stripping cookies from static files.
X-UA-FCF
Either allow or deny depending on whether or not the user has followed a link from Google, Facebook, or LinkedIn. To use the value of this header to construct a paywall or registration wall, see First Click Free support in Varnish.
Other headers
X-Acquia-No-301-404-Caching-Enforcement
By default, the Acquia Platform Varnish configuration caches all HTTP 301 (redirect) and HTTP 404 (not found) responses for a minimum of 15 minutes. If the application sends a max-age value greater than 15 minutes, Varnish uses the application value. If the application max-age is less than 15 minutes, Varnish overrides it to 15 minutes (900 seconds).
To override this behavior and give the application full control over caching for 301 and 404 responses, set the following response header in your application:
X-Acquia-No-301-404-Caching-Enforcement: 1
When this header is present, Varnish does not modify any of the response headers for 301 and 404 responses. The application’s max-age value is used without modification.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Note
If the Cache-Control header contains both s-maxage and max-age values, Varnish uses s-maxage to determine the cache lifetime for that request.
Server
The web infrastructure application (currently nginx) that acts as a load balancer to serve the content.
Vary
The inbound HTTP request headers that need to be taken into account when caching a single URL. The most common example is Accept-Encoding – a header that browsers usually send to websites to indicate whether they want the returned page compressed using gzip or the deflate compression algorithm. This can prevent serving gzip-compressed pages from cache to older browsers that do not support it.
Via
The web infrastructure application (currently Varnish) over which the request was sent.
A response header added when a request is forwarded to PHP-FPM. If PHP-FPM was not needed to serve this request, this header is not added.
X-AH-Environment
The Acquia environment that provides the page response. Usually prod, but could also include values such as dev or stage.
X-Cache
Either HIT or MISS depending on whether or not the item was served from the Varnish cache.
X-Cache-Hits
The number of times this object has been served from cache. Higher numbers indicate that this URL has received more visitors.
X-Drupal-Cache
Similar to X-Cache, this header indicates the outcome of Drupal’s page cache with HIT or MISS values. A MISS value is not unusual here. For more information about Drupal cache MISS, see Varnish cache HITS and Drupal cache MISS.
X-Forwarded-For
The originating IP address for a request.
X-Generator
The software used to create the page. On Cloud Platform, this says Drupal along with the version number of Drupal core.
X-Geo-Country
The two-letter ISO-3166–1 alpha-2 country code. Available only for Cloud Platform Enterprise and Site Factory subscriptions with dedicated load balancers. For more information, see Using GeoIP information.
Certain non-HTML static assets have cookie headers removed, and receive the HTTP request header X-Static-Asset:True. For more information, see Stripping cookies from static files.
X-UA-FCF
Either allow or deny depending on whether or not the user has followed a link from Google, Facebook, or LinkedIn. To use the value of this header to construct a paywall or registration wall, see First Click Free support in Varnish.
Other headers
X-Acquia-No-301-404-Caching-Enforcement
By default, the Acquia Platform Varnish configuration caches all HTTP 301 (redirect) and HTTP 404 (not found) responses for a minimum of 15 minutes. If the application sends a max-age value greater than 15 minutes, Varnish uses the application value. If the application max-age is less than 15 minutes, Varnish overrides it to 15 minutes (900 seconds).
To override this behavior and give the application full control over caching for 301 and 404 responses, set the following response header in your application:
X-Acquia-No-301-404-Caching-Enforcement: 1
When this header is present, Varnish does not modify any of the response headers for 301 and 404 responses. The application’s max-age value is used without modification.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform