I was wondering if we shouldn't rename "debug" to "strict".
But removing the mode altogether prevents seamless migrations.

I like the strict idea.

Maybe we could add astrict configuration parameter with a default fallback too true ?

yes, a config entry looks like an idea to consider to me
it would default to%kernel.debug% actually

yes, a config entry looks like an idea to consider to me
it would default to%kernel.debug% actually

Even better yes, I'll give a try

With this implementation, you'll have the following configuration available:

session:strict_stateless:true

With default configuration to%kernel.debug%

Thanks for creating this PR. The thing I don't like about the current implementation is thatstateless is unreliable. If you do this:

if (true ===$request->attributes->get('stateless')) {$response->setSharedMaxAge(3600);}

The problem is that, if the route uses the session, you may be caching a page with private information and serving it to anyone. That may be a very serious problem.

I don't like the idea of making this behavior configurable either. You said you weren't going to use the session ... so if you use it by mistake, the application should fail.

I think the transition will be OK, because developers will see the exceptions locally and fix them. So, in the remote case that you use the session in production when you shouldn't, I think that throwing an exception is better than silencing this error.

The problem is that, if the route uses the session, you may be caching a page with private information and serving it to anyone. That may be a very serious problem.

How can this happen? That's not possible to me, we have a mechanism that prevents it already.

We know by experience that it's very easy to use the session by mistake. For ppl that inadvertently render() a controller that uses the session, would they prefer a broken prod, or an automatic "cache-control: private"? The current way (since always) is the 2nd option and this should remain to me. With a line in the logs ftw. In dev, sure, I want an exception.

After discussing privately with Nicolas ... my main concern is now gone. In the previous example, Symfony will set "cache private" automatically because the session was used, so it will ignore our "smaxage" setting.

So, can anyone spot another issue for using the session in a controller that said that it was not going to use the session? Thanks!

Shall we close this PR then? One less option FTW.

Here is an excerpt of our conversation for the record:

Q:

if your app is not ready for this option ... you shouldn't need to worry about strict or not ... you just don't add stateless to your routes. do that only when you are ready, right?

A:

Nope: You declare it first, then you achieve it. And you know when you failed at it by logs or exceptions on dev. The only outcome of failing to comply is that cache-control private will be sent, exactly like today, which means you're safe.
A performance loss is a much better outcome than a broken prod.

Q:

In this code:
return $response->setSharedMaxAge(3600);
the cache private is automatically set?

A:

Yes: the session listener comes after and forces a private cc when the session is used, because nobody is able to correctly manage cc headers without privacy risks. That is the point of the new feature: Symfony protects privacy by default, but how do you achieve great cacheability? By patiently following the reports of the stateless mode; without breaking your prod; business is more important than cacheability all the time.

IMHO, some Symfony users may want to actually throw an exception even on production. In this way they'll be a hundred percent sure that session isn't used.

@mtarld my stand:

business is more important than cacheability all the time.

Fair enough. So if it shouldn't be configurable, we can close this PR I guess.