Too long X-Drupal-Cache-Tags headers (with 700+ cache tags) can cause HTTP 502 error with the following default configurations:
fastcgi_buffers: 16 32k
fastcgi_buffer_size: 32k
The usual result is:
upstream sent too big header while reading response header from upstream
The usual recommendation is tweaking the webserver configuration but based on my experience that is also not enough. Even if the HTTP 502 error goes away, the above mention header value remains empty:
Forms currently are not render-cacheable 📌 Form tokens are now rendered lazily, allow forms to opt in to be cacheable Needs review , but if you add an entity reference list like form element to a form that lists large amount entity labels and bubbles up cacheability information, the same can happen.
Generate more than one X-Drupal-Cache-Tags header when the number of cache tags exceeds a limit.
Closed: duplicate
9.4
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
For the record, it also triggers a 503 on Varnish, to detect it use the option -g session with varnishlog . It should returns (after a slight wait) the following error:
...
--- VCL_return fetch
...
--- BogoHeader Header too long: Cache-Tags: config:b
...