As I wrote on the linked PR:

Note that I didn't merge the check for no-store. It makes no sense to me.

So thanks for opening if this needs to be discussed.

Here is my reasoning:

#[Cache(noStore: false)] means: remove no-store from responses. That's what the implementation does indeed.
That "remove" semantic means there is something to be removed. Unless I missed something, no-store is not part of the defaults. Which mean if it's present, it was done explicitly. This PR is conflicting with this definition.

Here is my reasoning:

#[Cache(noStore: false)] means: remove no-store from responses. That's what the implementation does indeed. That "remove" semantic means there is something to be removed. Unless I missed something, no-store is not part of the defaults. Which mean if it's present, it was done explicitly. This PR is conflicting with this definition.

Thanks @nicolas-grekas !
I understand the concern, but the #[Cache] attribute's own documentation says:

Attributes define defaults, controllers have the final say, at least that's what I understood.

When a controller explicitly adds no-store at runtime, attributes shouldn't remove it because it's an intentional decision based on dynamic conditions that should be respected, just like the other directives.

@smnandre can you help us on this one since you added support for no-store on the cache attribute?

I'm trying to get a good comprehension of the issue here, reading the changes made since.

#62488 without something similar for no-store could not bring coherent results now indeed.

But I don't see how checking the header bag in foreach.. loops could be fully working, as multiple response setter act on two different headers, so one may just be decided by the other.

That beein said, I agree I did not implement it as "default header".. as I in fact never anticipate the usage of setting no-stiore "per default" and remove it explicitely later. But that was the same for public/private, no ?

@ayyoub-afwallah I'm curious too to understand the use case for

#[Cache(noStore: false)]
public function index(): Response
{
    $response = new Response();
    $response->headers->addCacheControlDirective('no-store');
    
    return $response;
}

Here it would make no difference if you removed the attribute entirely.

@smnandre thanks for the feedback!

I think the issue here is simpler than it looks, and it comes down to consistency and intent.

noStore: false almost has no real-world use case scenario:

#[Cache(maxage: 3600)]
#[Cache(maxage: 3600, noStore: false)] // exactly the same state

So the only time noStore: false has any effect today is when it strips a no-store directive that the controller explicitly added.

#[Cache(maxage: 3600, noStore: false)] // Implicitly: "Allow caching"
public function show(Article $article): Response
{
    // ...
    // Explicit runtime decision: "Don't cache this specific response"
    if ($article->isDraft() || $article->isPrivate()) {
        $response->headers->addCacheControlDirective('no-store'); // <- Developer's clear intent
    }

    return $response; // no-store is silently stripped by the attribute
}

This contradicts both the documented behavior and the established pattern for all other directives, i don’t see a clear reason why no-store should be the exception.

The best way for attribute and controller caching to coexist is to follow the existing documentation:

Headers defined in the Cache attribute are ignored if they are already set

The attribute defines the happy-path (or fallback) configuration, while the controller makes a contextual runtime decision based on information only available at execution time.

Overriding that explicit decision is surprising and breaks the mental model already established by all other cache directives.

To be honest, I understand the technical point, and yet I still don't see the problem.

As you said,

noStore: false almost has no real-world use case scenario
(...)
The only time noStore: false has any effect today is when it strips a no-store directive that the controller explicitly added.

Do you have any real-life scenario where someone would do this ?

#[Cache(maxage: 3600, noStore: false)] 
public function show(Article $article): Response
{
    // ...
    $response->headers->addCacheControlDirective('no-store');
}

instead of this

#[Cache(maxage: 3600)] 
public function show(Article $article): Response
{
    // ...
    $response->headers->addCacheControlDirective('no-store');
}

I think we all agree that #[Cache(noStore: false)] makes little sense.
Yet this PR doesn't either: if (false === $cache->noStore && !$hasNoStoreCacheControlDirective) then remove is just dead code.
Since we have a behavior that's defined for #[Cache(noStore: false)] at the moment, we should keep it, at least for BC reasons.
The correct path forward would be to deprecate #[Cache(noStore: false)] I suppose.
Let me close here.
Thanks for the discussion to everyone!