I tried to resolve the suggestion from @fabpot (#57852 (comment)) in the latest commit aa9e241

If we want to have only one place to deal with _stateless logic, we have to provide a way to know

• When the stateless attribute is set to false/true
• When the stateless attribute is not set (the has check)

This may be done by having a nullable boolean as return type of the isStateless method.

That doesn't change a lot to the check !$request->isStateless() since null and false behave the same way, but this allow to check null !== $request->isStateless() to reproduce the check $request->attributes->has('_stateless').

WDYT ?

having isStateless return bool|null looks weird to me as the name indicate a boolean.

Code wanting to guard session reads will only need a boolean anyway (as they don't need to distinguish the default case).
Special places needing to distinguish a request marked explicitly as stateful vs the default case (no explicit configuration) can check the attribute directly (and I doubt we will have lots of such use cases outside the core)

having isStateless return bool|null looks weird to me as the name indicate a boolean.

Code wanting to guard session reads will only need a boolean anyway (as they don't need to distinguish the default case). Special places needing to distinguish a request marked explicitly as stateful vs the default case (no explicit configuration) can check the attribute directly (and I doubt we will have lots of such use cases outside the core)

I reverted this in a17bfcd then @stof

After my comment in #57854 (comment), I'm wondering if this is common enough to deserve a dedicated method. I feel like this builds on a wrong definition of the _stateless attribute.

I feel like this builds on a wrong definition of the _stateless attribute.

I'm not sure to understand where is the wrong definition

Well it all boils down if you consider stateless as a check or as a directive.

The blog post which introduced it reads

Routes can now configure a stateless boolean option. If set to true, they declare that session won't be used during the handling of the request.

Note that it is written declare, not force.

If it doesn't force the session to be stateless, then this check shouldn't exists

And even if it's still a declaration, a way to know if the request is stateless should exists (in order to know if the session is useful/usable or not) and therefore a method would be better than having to know which private attribute is used.

Isn't isStateless a misleading name? What it returns is if the request is supposed to be stateless; if it has been configured as such.

Isn't isStateless a misleading name? What it returns is if the request is supposed to be stateless; if it has been configured as such.

Do you have a suggestion @MatTheCat ? "ShouldBeStateless" ?

I understand isStateless as "is declared Stateless", which is ok with your definition here: #57854 (comment)

shouldBeStateless sounds good to me indeed.

shouldBeStateless sounds good to me indeed.

Currently there is already some FirewallConfig::isStateless method. This one is not misleading ?

And setStateless is ok for the setter ?

Currently there is already some FirewallConfig::isStateless method. This one is not misleading ?

FirewallConfig::isStateless returns true if you configured the firewall stateless. Why would that be misleading?

When you configure a route stateless, you’re asking Symfony to warn you if the session is used. This does not offer any guarantee regarding the fact the session is used or not. As such, you cannot use this information to tell if the request is stateless or not. That’s why I think Request::isStateless is not a good name.

And setStateless is ok for the setter ?

Do you have use-cases in mind where a setter would make sense (if yes the name would be wrong the same way it is wrong for the getter)? 🤔

Currently there is already some FirewallConfig::isStateless method. This one is not misleading ?

FirewallConfig::isStateless returns true if you configured the firewall stateless. Why would that be misleading?

When you configure a route stateless, you’re asking Symfony to warn you if the session is used. This does not offer any guarantee regarding the fact the session is used or not. As such, you cannot use this information to tell if the request is stateless or not. That’s why I think Request::isStateless is not a good name.

IMHO part of my misunderstanding come from the fact that FirewallConfig::isStateless imply the fact that request is flagged as stateless. Reverting this behavior, as asked in #50715 (comment) would solve all my issues and avoid the need of this method.

And setStateless is ok for the setter ?

Do you have use-cases in mind where a setter would make sense (if yes the name would be wrong the same way it is wrong for the getter)? 🤔

No, it was just to be used in Symfony code (in order to avoid having to know the private attribute when setting it, but using the getter when accessing it).

I'd rather be 👎 here, reading the attribute is fine, and the setter doesn't really make sense to me. This gives too much visibility to the setting IMHO.

Symfony does not enforce requests to be fully stateless so isStateless would potentially bring false impressions, and I don’t get the need for shouldBeStateless() in userland.
Let’s close. Thanks for proposing @VincentLanglet.

Symfony does not enforce requests to be fully stateless so isStateless would potentially bring false impressions, and I don’t get the need for shouldBeStateless() in userland. Let’s close. Thanks for proposing @VincentLanglet.

Yes, and personally I never used stateless request, I just needed a check because the request was declared stateless when I use stateless firewall...
Since #58017 is merged, I won't need to check it again.

I have worked on several applications that made unnecessarily heavy use of the session before the decision was made to transition towards a RESTful API. It has always been hard to trace down where the stateless request processing is "tainted" by an unexpected session access. I think, Symfony could implement tooling to help with such a transition.

Maybe this PR wasn't the right way (and the now-reverted logic for auto-flagging requests in stateless firewalls wasn't either), but I think we should continue talking about how we could tackle stateful/stateless requests better. Maybe we should start over with an issue where we could discuss the topic?

Maybe this PR wasn't the right way (and the now-reverted logic for auto-flagging requests in stateless firewalls wasn't either), but I think we should continue talking about how we could tackle stateful/stateless requests better. Maybe we should start over with an issue where we could discuss the topic?

Do you think the discussion could be done in the issue #57502 @derrabus or it would require a different one ?

reading PRs/issues/discussions on such request stateless topic, we can see the "misleading/misusage" of such point
same as you on this

Maybe we should start over with an issue where we could discuss the topic?

I do think this is a good starting point yes (or use existing one?)

Do you think the discussion could be done in the issue #57502 @derrabus or it would require a different one ?

I missed that one. Of course, let's continue the discussion there.