X-Drupal-Cache-Tags / X-Drupal-Cache-Context header tags can exceed HTTP Server limits and cause WSOD

I stumbled across this error today as well for a specific content type (add/edit).

Whereas setting

http.response.debug_cacheability_header

to false in development.services.yml does allow the page to load, it doesn't fix the underlying issue.

Can you explain why you think this is a bug in Drupal?

If you don't notice this problem while developing, what happens if you deploy to production on sites that are using e.g. https://www.drupal.org/project/purge or https://www.drupal.org/project/fastly?

I ran into this issue on Drupal 8.5.5 inside of https://www.drupalvm.com/, default Apache 2.4.18 settings. The issue occurs when docroot/sites/development.services.yml has http.response.debug_cacheability_headers to "true". I confirmed that even with advagg module uninstalled this setting will cause WOSD.

Here is the error I saw in apache error log:

[Wed Jul 18 19:01:30.597148 2018] [proxy_fcgi:error] [pid 1396:tid 140595418789632] [client 10.20.1.1:51824] Premature end of script headers: index.php, referer: http://drupal.local/
[Wed Jul 18 19:01:30.597190 2018] [proxy_fcgi:error] [pid 1396:tid 140595418789632] [client 10.20.1.1:51824] AH01070: Error parsing script headers, referer: http://drupal.local/
[Wed Jul 18 19:01:30.597194 2018] [proxy_fcgi:error] [pid 1396:tid 140595418789632] (22)Invalid argument: [client 10.20.1.1:51824] AH01075: Error dispatching request to : , referer: http://drupal.local/

The solution for me was to change http.response.debug_cacheability_headers to "false".

Encountered this with 8.5.6. Fixed after setting http.response.debug_cacheability_headers to false.

I'm experiencing the same issue which is breaking Pound proxy (v. 2.7). Setting http.response.debug_cacheability_headers to FALSE fixes the WSOD. Drupal core 8.6.1.

I hit this problem as well when re-syncing my development site to the current production site.

It is a Drupal bug because Drupal code produces a header that breaks Apache's rules. The code to produce this tag should not create a tag greater then the standard Apache limit. Instead it should break them up to multiple X-Drupal-.. tags.

The current code simply implodes the list of cache and context tags without checking it's length. The code should do something like the psuedo code below for both X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts tags.

<?php
static MAX_LENGTH = 8000; // A bit of headroom from the 8190 Apache max
$cache_tags = implode(' ', $response_cacheability->getCacheTags()));
if ( strlen($cache_tags) < MAX_LENGTH ) {
  $response->headers->set('X-Drupal-Cache-Tags', implode(' ', $response_cacheability->getCacheTags()));
}
else {
  // loop thru cache tags testing length and setting multiple headers with shortened cache tag value
}
?>

Updated the title to indicate bug.

Changed category to bug since Drupal is causing the WSOD

Changed Status to active since there is a proposed strategy for fixing this.

We are running to the same error as #14 We are wondering if someone knows the progress about this bug. Does Drupal follow this bug or not? Thank you guys, for further information.

We are using Apache 2.4.29-1ubuntu4.5 and PHP php-fpm 7.2.10-0ubuntu0.18.04.1

Does Drupal follow this bug or not?

Yes. This is the Drupal issue queue.

+++ b/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php
@@ -154,8 +154,14 @@ public function onRespond(FilterResponseEvent $event) {
+      foreach (explode("\n", wordwrap($cache_tags, 8000)) as $delta => $tags) {

8000 should not be hard coded. At least needs a constant (for both places it is used)

This issue seems to be a duplicate of #2844620: Automatically split cache debug headers into multiple lines when they exceed 8k. Since that issue is older, I'm closing this one in favor of the older one.

The hardcoding of the maximum length is discussed in that issue, as well as a possible solution to dynamically determine the max header size.

Thanks @michaellenahan the patch fixed my issue. If this issues is getting close, the patch probably should get added to the older issue.

Credit belongs to vaza18 for a very elegant solution. I simply added some boilerplate code. It would be nice to get this resolved, this issue has caused a lot of unnecessary pain for developers.

Thanks @michaellenahan, the patch fixed the issue.

Thanks so much michaellenahan

that saved my day after hours of dealing with a server with restricted access and useless logs. And then applying this patch and hours of agony came to an end....

Got this pain in drupal 8.9.7 dev mode, the solution was `drupal smo prod`.

Update for patch in #21 against 9.2.x since I'm still using it

The same bug reported in ASF Bugzilla:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64919

I have not found if this is fixed by Apache.

Update of the previous patch for 9.3.x

This has been closed as duplicate, proceed here please: #2844620: Automatically split cache debug headers into multiple lines when they exceed 8k

Until the fix is merged into core, here is a re-rolled version of patch#36 that uses the sorted cache tags prior to splitting. Also note that this patch is applicable for Drupal 10.4.x as well.

Alternatively, contrib module Debug Cacheability Headers Split to overcome this issue.