docksal: Getting "AH01070: Error parsing script headers" from web (Apache) container on certain pages with Drupal 8
Logging mostly as FYI so others can find it.
This has been recently mentioned on Gitter. I also ran into this issue myself today:
[Mon Aug 05 13:44:36.060195 2019] [proxy_fcgi:error] [pid 12:tid 140074858306280] [client 192.168.160.2:46478] Premature end of script headers: index.php
[Mon Aug 05 13:44:36.060257 2019] [proxy_fcgi:error] [pid 12:tid 140074858306280] [client 192.168.160.2:46478] AH01070: Error parsing script headers
[Mon Aug 05 13:44:36.060263 2019] [proxy_fcgi:error] [pid 12:tid 140074858306280] (22)Invalid argument: [client 192.168.160.2:46478] AH01075: Error dispatching request to :
192.168.160.2 - emmis [05/Aug/2019:13:44:35 +0000] "GET /admin/content/media HTTP/1.1" 500 -
The problem is with Drupal sending enormous headers and hitting the default 8k limit in Apache: http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize
Increasing LimitRequestFieldSize to 16380 (or more) may alleviate the issue, however, it looks like this has to be addressed in Drupal.
Upstream issue with a proposed patch: https://www.drupal.org/project/drupal/issues/2844620#comment-13126836
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 18 (8 by maintainers)
From https://www.drupal.org/project/drupal/issues/2844620#comment-13354686, this worked for me:
For others experiencing this issue we noticed our development.services.yml file had the following configuration:
http.response.debug_cacheability_headers: true
Changing this to false sorted the issue.
I have had the same error and I believe this is caused by https://www.drupal.org/project/drupal/issues/2954339. The fix at https://www.drupal.org/project/drupal/issues/2954339#comment-12609045 resolved the problem for me.
Adding httpd-vhost-overrides.conf to my Docksal config didn’t help.
Disabling debug_cacheability_headers worked for me, though for me it was located at sites/default/services.local.yml. This took me a while to figure out because both services.local.yml and development.services.yml existed in my code base, but only one was used.
The above was tagged as a duplicate of https://www.drupal.org/project/drupal/issues/2844620. The latest patch in that issue supposedly fixes the problem, but whether or not this is something that should also be applied to a non-development environment should be interpreted on a case-by-case basis. It might be that just setting
http.response.debug_cacheability_headertofalseis all that is needed if the problem isn’t occurring in production.In our case it wasn’t Drupal’s fault - we have an insanely complex system which can easily generate a thousand or more cache tags for a page. And we use Fastly, so even with debug_cacheability_headers set false, it’s still sending upwards of 5K in cache tags to Fastly (then add everything else in the headers).
Haven’t solved it for us yet but I thought I’d add this in here in case someone else uses Fastly and is confused.