Introduce "Vary" page cache response policy

Contrib blocker, see: #3222748-30: Create a page if given internal path is not valid →

Addressed point #14.2 of comment #14, keeping the status needs work for comment #14.1.

Any update on this issue?
Will this be included in core?

🐛 Browser language detection is not cache aware Needs work has been updated to use a responsesubscriber that allows setting Vary headers. Wonder if those changes also need partial split into this issue?

From #4...

Regrettably this approach clearly violates the ResponsePolicyInterface contract. While not stated explicitly in the documentation, the check() method is certainly not expected to actually change the response.

I don't think this is resolved with the current approaches still, as suggested in #26.
I have solved this in my own project with an event subscriber for KernelEvents::RESPONSE. I think that would be a relatively simple change to make here. Would that address the concerns of #4?

Sorry @bbrala - this is nearly the same thing you are suggesting as well... but I do think that issue #2430335 would do most of what this issue is trying to do from what I can see.

As commented in https://www.drupal.org/project/drupal/issues/2972483 🐛 Page Cache must respect Vary, otherwise it might serve mismatched responses. Active , I've developed the module page_cache_vary → until the issue is fixed in the core page_cache module.

It can retrieve cache vary headers by caching them per URL, so that the cost of computing the vary headers is as minimal as possible.

If this solution is good enough, I can try to integrate it directly in Drupal, let me know what you think.

Talked with catch avout a possible angle of attack which would make this viable (possobel) from a variation and perdormance perspective. Will post that sometime soon.