Allow a header value size limit to be specified

+++ b/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php
index fea9762..a516607 100644
--- a/sites/default/default.services.yml

--- a/sites/default/default.services.yml
+++ b/sites/default/default.services.yml

+++ b/sites/default/default.services.yml
+++ b/sites/default/default.services.yml
@@ -1,4 +1,7 @@

@@ -1,4 +1,7 @@
 parameters:
+  # Header value size limit in bytes. -1 means infinite, no limit.
+  # @default -1
+  header_value_size_limit: -1

Can we put the default value into core.services.yml as well?

+++ b/core/lib/Drupal/Core/EventSubscriber/CacheableResponseSubscriber.php
@@ -0,0 +1,131 @@
+    // When there is no limit, we never map cache tags to hashes.
+    if ($this->limit !== -1) {
+      // Also invalidate the cache tags as hashes, to automatically also work
+      // for cached responses that exceed the header size limit.
+      // @todo this causes infinite recursion… any ideas for a work-around?
+      Cache::invalidateTags(static::cacheTagsToHashes($tags));
+    }

just add a static var to detect the recursive calls?

#6: That is a good reasoning, but the problem is the upgrade path again:

Think of it like:

variable_get('foo_variable', 'default');

And then in settings.php a:

#$settings['foo_variable'] = 'some-value';

Container parameters don't have a default, so core.services.yml _is_ our default as container parameters are overwritten by whoever comes last in $settings['container_yamls'].

If we don't have a default in core.services.yml or for a core module in module/module.services.yml then updating core versions fails as the parameter is missing.

That is why we need both IMHO.

Re #7: I tried the static variable approach, and it seems to be working.

  /**
   * Static variable to control recursion in the invalidateTags method.
   * @var bool
   */
  private static $recursionStop = FALSE;

  /**
   * {@inheritdoc}
   */
  public function invalidateTags(array $tags) {
    // When there is no limit, we never map cache tags to hashes.
    if ($this->limit !== -1) {
      // Also invalidate the cache tags as hashes, to automatically also work
      // for cached responses that exceed the header size limit.
      if (!static::$recursionStop) {
        static::$recursionStop = TRUE;
        Cache::invalidateTags(static::cacheTagsToHashes($tags));
        static::$recursionStop = FALSE;
      }
    }
  }

Just uploading this to see if it fails tests.

Go testbot go! Make me proud!

Here's another attempt at this.
I put the default value in core.services.yml. I'm also thinking there should be a test for this, but I'm not really sure how to make that work, so any thoughts would be great.
Thanks,

Reroll of #14 attached.

 parameters:
+  header_value_size_limit: -1

http.response.header.max_length would be a much more appropriate parameter name.

The solution we arrived at there is to never send the X-Drupal-Cache-Tags header except for debugging (and tests; because otherwise we would break existing tests).

Uhm. And actually using them for varnish etc. cache invalidation? :)

I'm not sure if we need this or not, but that argument doesn't really work ;)

@Berdir - the idea is that cache tag headers will be emitted by Cloudflare module, Varnish module, etc. Core is no longer in the business of sending production headers.