Actually that's expected behavior: this page is not cachable - it used the session to be generated.
See #24774, which fixed the isStarted check.

@nicolas-grekas I don't quite understand, then. As my code didn't explicitly start and doesn't need it, can I disable the session functionality completely or is that required by the profiler to function?

@nicolas-grekas: This is what I was talking about when you started the session refactoring. The framework or it's debug components shouldn't start the session unless it has been started by the developer's code explicitly.

This looks like a huge bug to me introduced with #25583. RequestDataCollector always starts the session and then SaveSessionListener will always mark the request uncachable due to #25583. So even if you don't use a session, the no cache headers will be set automatically.

As stated above, this is not a bug to me, and this is totally independent from #25583.
See #24774: the profiler cannot work without the session, so it has to use it.
This is just normal behavior and a side effect of using the profiler. Not doing so means re-introducing #24730.

This make a little more sense to me now, so

A session is required for the profiler to work (to catch redirects I believe)

A session being started (even for an indirect reason such as this) means the response should be considered private, even if this could sometimes be inconvenient.

But, do we really need to setMaxAge(0) and override what a dev has specified as the cacheability for a response in their controller? And if we do, I think this should be clearly explained in the documentation on caching, as following the instructions in the docs in a dev environment don't seem to work right now.

Actually, this may be fixable: we should just not use the session to forward the sf_redirect array from one request to another, and just use a json_encoded cookie (or URL parameter BTW)!
@adamquaile would you like to give it a try?

we should just not use the session to forward the sf_redirect array from one request to another, and just use a json_encoded cookie

It's a tradeoff: using a cookie would mean that both the redirection and the target page will not be cachable (because of the Set-Cookie to set the sf_redirect and the one to clear it).

or URL parameter

IMHO that might confuse developers, but there are less hidden moving parts, so this might be a good idea, you've got my 👍 on this one.

Depending on the feedback, I'm happy to help going to either direction by PRing the changes.

I think a URL parameter might be the simplest here, because there's no need to really clear it. I can imagine browser extensions or settings potentially causing more problems with cookies too. Happy to help on this when I next get a chance too, if that's the way people want to go.

The obvious problem is the URL parameter is that it requires the user to generates the URL using Symfony's router, and would require the HttpKernel component to know about it... which is not going to work well IMHO. The Cookie option seems to be the only suitable alternative.

See #25719