Add http.response.debug_cacheability_headers: true to development.services.yml

Good idea!

Including parameter http.response.debug_cacheability_headers as true for development environments as the proposed resolution by @tstoeckler

@tstoeckler you are right, I just realize that after uploading. =) I just generated a new one

ops, removing extra line in the end of file

Committed and pushed 37db2b5 to 8.3.x and bddce2c to 8.2.x. Thanks!

I committed this to 8.2.x as it is a DX improvement with no run-time impact. In fact this file should almost be viewed as documentation.

Can you next time please comment on the associated issue, to get reviewers who followed that issue?

Big +1 of course!

After upgrading from 8.1 to 8.2, I got the following error in my Apache error_log:

[core:error] Premature end of script headers: index.php

..using Dev Desktop ver. 2 with mod_fastcgid (FastCGI) as development environment. The reason behind is that the cachetags exceed the given limit of the header size.

Setting http.response.debug_cacheability_headers to false in development.services.yml "fixes" the problem for me.

Alternative / better solution might be raising the header field limit in the Apache/FastCGI configuration.

Thanks to the post in #15 for this. It is actually very common on complex sites to exceed the Apache header size with too many cache tags, especially when logged in as a user looking at a listing page with lots of nodes that are cached per-user because of node-history.

Not sure why it was decided making this the default was good. It causes a white-screen crash in Apache that is difficult to debug.

@alexpott wonder why in #12 this was considered "no impact". Is there some other way we should be limiting the size of the cache headers? Or what am I losing by having this False.

Geez, I finally got here after finding that http.response.debug_cacheability_headers fixes the error as stated on #15.

I second this was super hard to find. I was close to just call it a day and install nginx just for the one project where this happened to me. It's not so big though, it's actually pretty simple.

I think this worth a further discussion, just created #2954339: X-Drupal-Cache-Tags / X-Drupal-Cache-Context header tags can exceed HTTP Server limits and cause WSOD to follow this up.

I ran into this issue and will comment on #2954339.

Final issue for this topic: #2844620: Automatically split cache debug headers into multiple lines when they exceed 8k
Just ran into this issue again with http.response.debug_cacheability_headers: true!