FrankenPHP now hard links against php-session

[henderkes]

What happened?

It is no longer possible to compile frankenphp for php without session support, meaning that if someone were to not install the php-session extension, not only would frankenphp possibly crash, but it's also not possible to compile frankenphp anymore without first having built php-session.

We're unconditionally including ext/session/php_session.h

Build Type

Custom (tell us more in the description)

Worker Mode

No

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

-

Relevant log output

-

[henderkes]

https://github.com/static-php/packages/actions/runs/22015353484/job/63616165528

[AlliBalliBaba]

I still dislike the reset logic from #2139 since it's way too specific to Symfony 5. I'd rather remove it than try to accommodate every single use case for native sessions (see #2185).

[henderkes]

I'm with you there. The ini settings I think absolutely, but I just don't see the session stuff to be on frankenphp's side.

[dunglas]

What do you suggest we do then?

[henderkes]

Personally? Remove the opinionated session handling from FrankenPHP but keep the ini resets.

[dunglas]

@xavierleune WDYT?

@henderkes you mean resetting $_SESSION? To me, this super global is related to the currently handled requests, so it makes sense to reset it as we do for $_POST and the like.

[henderkes]

The alternative is to link against php_session.h conditionally, based on whether the extension is detected or not. But, unlike for ini settings, I don't see what the $_SESSION reset actually improves. Is it just in case a previous request calls session_start(), never closes it and the next request accesses $_SESSION without session_start()?

[henderkes]

another issue caused by this: #2190

[AlliBalliBaba]

Sessions were not broken before #2139. That PR just adds logic to persist session handlers across requests, which only fixed Symfony 5 (unmaintained), but apparently broke later Symfony versions.

[xavierleune]

Hi,

Sorry if my pull request caused some bugs. There is a lot to unfold here, but before digging into technical stuff I think I should explain my point.

As a newcomer I had some assumptions about worker mode, that may be wrong. Here are the first that comes to my mind:

• nothing I make in the request 1 should make the end of the request 2 crash the php engine. That's like super hard to understand and debug. Either it crashes on request 1, or never.
• the internal state of the php engine should not be affected by requests handled in worker mode, that's impossible to debug and understand
• sessions may never leak between requests. If I keep a reference to the user, that's on me. But in no case I should have access to session details from a previous request. That's a serious security issue, even if hard to exploit.
• worker mode is not symfony or laravel only.

So this assumptions really have nothing to do with symfony (5 or later). The only reason we are talking about sf is because:
1- I had a crash (unrelated to sf)
2- I found the exact same log in an issue that was about sf
3- I linked that issue when I submitted a patch
But my use case was not about symfony.

So about the technical stuff I'm pretty sure we can find a way to handle it, but as @henderkes (maybe ? Or maybe @AlliBalliBaba sorry) pointed out in a previous comment, we should draw a line about how worker mode behaves in that kind of situation.

I'm a big fan of worker mode and how it's handled, again I'm new to it and I may be wrong about a lot of things. And I'm sorry if I'm, I think that making this clarification may help a lot of newcomers to know what to expect from worker mode and how to deal with it.

Thanks a lot for your feedback and your help.

[AlliBalliBaba]

It's completely fine to try and fix sessions this way, you had a bunch of great PRs 👍. Persisting session handlers just feels like it fixes one problem while creating a bunch of others, since not everyone might want to have the handlers persist. So I'd rather keep it simple and just reload the entire session module.

[henderkes]

Yeah this actually also just broke form submission in production for me. We should push a 1.11.3 hotfix as soon as we can.

[xavierleune]

@henderkes may you please try #2193 and tell me if it's working for you ? I could not create a proper reproducer in tests for that use case.
Thanks !