Create versions of `session_decode()` and `session_encode()` that don't rely on `$_SESSION` global state

[mbabker]

Description

When working with the serialized session data in userland that isn't serialized using the php_serialize option for the session.serialize_handler configuration, trying to read that data currently requires writing a custom reader since session_decode() will decode the given data and write to $_SESSION, which is not optimal in some circumstances. In the documentation, there is a workaround in the notes that worked well prior to PHP 8.3 and used in libraries including Ratchet, but after the Make unserialize() emit a warning for trailing bytes RFC, it spits warnings and requires a custom implementation which tries to emulate the native PHP handling.

It would be great if there were a version of the session_decode() and session_encode() functions that could be exposed to userland that wasn't arbitrarily tied to the $_SESSION superglobal, allowing users to decode and encode session data using the existing serialization logic without needing to reinvent the wheel.

[nielsdos]

but after the Make unserialize() emit a warning for trailing bytes RFC, it spits warnings and requires a custom implementation which tries to emulate the native PHP handling.

Why can't you silence the warning using e.g. @ ?

[mbabker]

Why can't you silence the warning using e.g. @ ?

We can, but I also think we can do better and avoid the warnings. In this case, we have data that can be serialized and deserialized safely by PHP's internals, but it's not as accessible to userland. Sure, we could also switch to php_serialize for the session serializer and not have to deal with the custom format or the possible warnings, but it also has the side effect of breaking the existing session data.