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.

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¶

• 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.

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

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

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