Application Launcher

Date Published: February 6, 2025

Issue

When too much HTTP header data is sent back during an HTTP response, these can be logged as a successful response on the Web (Apache/PHP) layer (showing a "200" status code on access.log), but trigger a 503 sent back to the browser/client.

An example of an HTTP header response that has the potential to be too large could be the following,

# Invoke curl and show HTTP response headers
$ curl -sIXGET http://www.examplesite.com

{... snip}

Link: ; rel="alternate"; hreflang="en"
Link: ; rel="alternate"; hreflang="it"
Link: ; rel="alternate"; hreflang="ar"
Link: ; rel="alternate"; hreflang="bg"
Link: ; rel="alternate"; hreflang="zh-hans"
Link: ; rel="alternate"; hreflang="zh-hant"
Link: ; rel="alternate"; hreflang="hr"

{... snip}

X-Generator: Drupal 8 (https://www.drupal.org)
X-Request-ID: v-abcd1234-1234-1234-abcd-abcd1234abcd
Access-Control-Allow-Headers: *, access_token, authorization, client_id, Accept, Accept-CH, Accept-Charset, Accept-Datetime, Accept-Encoding, Accept-Ext, Accept-Features, Accept-Language, Accept-Params, Accept-Ranges, Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Origin, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Request-Headers, Access-Control-Request-Method, Age, Allow, Alternates, Authentication-Info, Authorization, C-Ext, C-Man, C-Opt, C-PEP, C-PEP-Info, CONNECT, Cache-Control, Compliance, Connection, Content-Base, Content-Disposition, Content-Encoding, Content-ID, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Script-Type, Content-Security-Policy, Content-Style-Type, Content-Transfer-Encoding, Content-Type, Content-Version, Cookie, Cost, DAV, ...
... {MANY more items in the same line deleted for clarity } ...
... Duration, X-Content-Security-Policy, X-Content-Type-Options, X-CustomHeader, X-DNSPrefetch-Control, X-Forwarded-For, X-Forwarded-Port, X-Forwarded-Proto, X-Frame-Options, X-Modified, X-OTHER, X-PING, X-PINGOTHER, X-Powered-By, X-Requested-With, ActiveSegments, x-locale

{... snip... more (but smaller) headers follow}

In the example above, you have 2 problems:

There are many Link headers; too many headers can cause problems
There is an extremely long Access-Control-Allow-Headers header; too-long headers can cause problems as well.

Resolution

Since there is a hard limit in Acquia Cloud around the size and number of headers a response can have, you must reduce the amount of headers and/or data via various strategies.

Reduce site complexity by disabling some modules or turning off some functionality.
Limiting the header data using a special custom module
Configuring one or more Drupal modules (or Drupal core) to output less data.
Deeper analysis using XDebug and an IDE (like the Acquia Cloud IDE) to inspect the header data or other code logic as pages are built.

Note: To help troubleshoot this issue, you can install the EXPERIMENTAL module Large Headers ; see its README for steps on how to use. If possible, we recommend only using it on non-production environments. This module will note whenever large amounts of header data is present and put it into a logfile.

Here are some common causes of this problem, as seen by Acquia Support:

Common cause: Using Drupal core's cache tags debugging

Cache tags are a Drupal method to make cache maintenance more efficient. You can read about it here .

If you have enabled cache tags debugging (i.e., you set http.response.debug_cacheability_headers to 'true' in your Drupal site's services.yml file) your site can start dumping large amounts of data into a X-Drupal-Cache-Tags HTTP response header. This may cause problems on your site. In general we do not recommend enabling this option on Acquia Cloud; however, it may be OK to do so inside a Cloud IDE or a local environment.

For more about cacheability headers debugging, see https://www.drupal.org/docs/8/api/responses/cacheableresponseinterface#debugging

Common cause: pages with too many elements causes Acquia Purge to output large cache tag data in HTTP headers

The Acquia Purge module helps keep your Varnish (and Platform CDN) cache in sync with any site changes. It does so by using a shortened version of the Drupal cache tags output generated by this code .

If you are using the Acquia Purge module, having pages that have many views items, many blocks, paragraphs and/or any other types of Drupal entities can cause too many Cache Tags to be output in a header. These cache tags are needed to ensure that the Acquia Purge module can clear out pages from Varnish (and possibly from the Acquia Platform CDN) when editors on your site add/change/remove content or configuration from your site. This ensures your site is cached as much as possible, while also allowing editorial changes to display as soon as possible.

Some steps to simplify pages that have this issue:

If your page contains any Views, edit the view so that less items are shown, and/or use paging or lazy loading method to limit the complexity of data returned by Drupal.
Reduce the amount of blocks, views and/or any other content components on the page.

As an alternative, you can test briefly disabling the Acquia Purge module and setting a low page cache maximum age at your Drupal admin page /admin/config/development/performance

Common cause: Security Kit module has been configured to output very long HTTP headers

If you have the Security Kit module, ensure the module settings are not putting too much data into your headers. This includes:

Access-Control-Allow-Headers
Content-Security-Policy
Strict-Transport-Security
and various others.

Note that the values in these headers are directly editable by a Drupal site builder; you can just manually edit the settings at /admin/config/system/seckit .

To ensure your site remains secure without exceeding the header size constraints on Acquia Cloud, it may be necessary to fine-tune your settings. Utilize resources such as the Content Security Policy (CSP) documentation or leverage tools like Mozilla Observatory and CSP Evaluator for guidance in achieving an optimal balance.

Common cause: the D8 Core Content Translation module

A common issue is triggered by the Content Translation code module adding many "Link" headers on a response. The Content Translation module exposes link relations both at the HTTP level (Link response header) and the HTML level (<link> tag in HTML <head>). This can easily exceed the number of allowable headers. The particular Link headers are generated because of this code within content_translation_page_attachments():

$page['#attached']['html_head_link'][] = [
  [
    'rel' => 'alternate',
    'hreflang' => $language->getId(),
    'href' => $url,
  ],
  TRUE,
];

To alter the module behavior so that it no longer adds a Link response header, you can create a custom module and implement hook_page_attachments_alter() to set the boolean to FALSE for all html_head_link elements. See the Drupal API documentation for hook_page_attachments_alter().

Cause

On Acquia Cloud, the soft limit is 60 individual headers and/or a combined total of 23kb of header data. Requests which exceed the soft limit may serve 503 status codes from Varnish and 200 from the Apache backend.

Drupal 8+ and certain contributed modules may increase the size of headers sent out with each response, and cause problems like those mentioned above.

The Drupal community is aware of the dilemma of having Drupal output headers that depend on content and/or user configuration, vs. the practical limits of different available hosting platforms (not just Acquia Cloud). See the ongoing discussion here: https://www.drupal.org/project/drupal/issues/2844620