# User defined session serialize handler

- Thread: https://externals.io/message/81065
- Original archive: https://news-web.php.net/php.internals/81065
- Started by Yasuo Ohgaki on 2015-01-24T02:28:07+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #81065 — Yasuo Ohgaki — 2015-01-24T02:28:07+00:00

URL: https://externals.io/message/81065#81065

Hi all,

Session module has session serializer modules that serializes $_SESSION
back and forth.
Session serializer module can be defined by user if there is API for it. I
would like to
propose user defined serialize handler API.

The user defined serializer API will have similar API like
 `session_set_save_handler()`.

bool session_set_save_handler(callable $serialize_callback, callable
$unserialize_callback)
bool session_set_save_handler(SessionSerializer $serializer);

interface SessionSerializer {
  public string function serialize(array $_SESSION); // Return serialized
session data
  public bool function unserialize(array &$_SESSION, string $session_data);
// Initialize $_SESSION by $session_data
}

php.ini :
 There is "session.serialize_handler" (Default: php) "user" will be added,
but user must use
 session_set_serialize_handler() just like `session_set_save_handler()`.

I also would like to php_serialize handler as the default serializer and
make php/php_binary deprecated.

php/php_binary serializers are made to work with register_globals and have
many limitations.
e.g. Integer key not allowed, key cannot start with number, delimiter chars
are invalid and
ignored, etc. php_serialize does not have such limitations at all.

Thank you for your feedback.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #81066 — Yasuo Ohgaki — 2015-01-24T02:36:27+00:00

URL: https://externals.io/message/81065#81066 · In reply to: #81065

Hi all,

Additional comments.



> php.ini :
>  There is "session.serialize_handler" (Default: php) "user" will be added,
> but user must use
>  session_set_serialize_handler() just like `session_set_save_handler()`.
>
> I also would like to php_serialize handler as the default serializer and
> make php/php_binary deprecated.
>
> php/php_binary serializers are made to work with register_globals and have
> many limitations.
> e.g. Integer key not allowed, key cannot start with number, delimiter
> chars are invalid and
> ignored, etc. php_serialize does not have such limitations at all.
>

php_serialize uses plain PHP serialize/unserialize for $_SESSION. i.e.
Serialized data is the same
as serialize($_SESSION).  php_serialize is introduced from PHP 5.5.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #81067 — Thomas Bley — 2015-01-24T03:45:22+00:00

URL: https://externals.io/message/81065#81067 · In reply to: #81065

Sessions take a big amount of data in production systems, so it might be worth to use msgpack (or others) as an option.

Regards
Thomas


Yasuo Ohgaki wrote on 24.01.2015 03:28:

> Hi all,
> 
> Session module has session serializer modules that serializes $_SESSION
> back and forth.
> Session serializer module can be defined by user if there is API for it. I
> would like to
> propose user defined serialize handler API.
> 
> The user defined serializer API will have similar API like
> `session_set_save_handler()`.
> 
> bool session_set_save_handler(callable $serialize_callback, callable
> $unserialize_callback)
> bool session_set_save_handler(SessionSerializer $serializer);
> 
> interface SessionSerializer {
>  public string function serialize(array $_SESSION); // Return serialized
> session data
>  public bool function unserialize(array &$_SESSION, string $session_data);
> // Initialize $_SESSION by $session_data
> }
> 
> php.ini :
> There is "session.serialize_handler" (Default: php) "user" will be added,
> but user must use
> session_set_serialize_handler() just like `session_set_save_handler()`.
> 
> I also would like to php_serialize handler as the default serializer and
> make php/php_binary deprecated.
> 
> php/php_binary serializers are made to work with register_globals and have
> many limitations.
> e.g. Integer key not allowed, key cannot start with number, delimiter chars
> are invalid and
> ignored, etc. php_serialize does not have such limitations at all.
> 
> Thank you for your feedback.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

---

## #81071 — Yasuo Ohgaki — 2015-01-24T09:03:19+00:00

URL: https://externals.io/message/81065#81071 · In reply to: #81067

Hi Thomas,



> Sessions take a big amount of data in production systems, so it might be
> worth to use msgpack (or others) as an option.


Yes, it is.
PHP's serialize (both php/php_serialize handler uses PHP's serialize) is
not a fastest serializer.
msgpack seems good. I'll try few serialize methods see if there is good one
or even may write
binary serializer for the best performance. Once user defined session
serialize handler is
implemented, users may try various serializers by themselves, too.

Thank you for your feedback!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #81077 — Rowan Collins — 2015-01-24T15:35:38+00:00

URL: https://externals.io/message/81065#81077 · In reply to: #81067

>Sessions take a big amount of data in production systems, so it might
>be worth to use msgpack (or others) as an option.

This came up before, and it was pointed out that a fast implementation of something like msgpack would need to be implemented as an extension anyway, not userspace code. And extensions can already register a serialisation handler, so do not need a userspace callback; I believe igbinary implements this, for instance.

---

## #81078 — Rowan Collins — 2015-01-24T15:42:26+00:00

URL: https://externals.io/message/81065#81078 · In reply to: #81065

>I also would like to php_serialize handler as the default serializer
>and
>make php/php_binary deprecated.
>
>php/php_binary serializers are made to work with register_globals and
>have
>many limitations.
>e.g. Integer key not allowed, key cannot start with number, delimiter
>chars
>are invalid and
>ignored, etc. php_serialize does not have such limitations at all.

I'm in favour of this part. In the unlikely event that someone needs to access the same session data with PHP 5 and 7, they should be able to switch back to the old format, but for most users, plain serialise is a much more sensible format.

An additional problem with the existing format is that there are no functions to work with it outside of the $_SESSION array, so you can't just unserialize a local copy.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #81079 — Yasuo Ohgaki — 2015-01-24T16:20:26+00:00

URL: https://externals.io/message/81065#81079 · In reply to: #81077

Hi Rowan,

On Sun, Jan 25, 2015 at 12:35 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 
> > […]
>
> This came up before, and it was pointed out that a fast implementation of
> something like msgpack would need to be implemented as an extension anyway,
> not userspace code. And extensions can already register a serialisation
> handler, so do not need a userspace callback; I believe igbinary implements
> this, for instance.


I agree that fast serializer should be implemented by native code.

However, once user serialize handler is implemented, overhead of user
serialize handler is calling 2 PHP functions. i.e. serialize/unserialize
functions whatever module provides. Users may compress/encrypt session data
whatever methods also. If user wants serialize/compress/encrypt, 6 PHP
functions calls are required. It would be reasonably fast. User serialize
handler provides much freedom than now.

I cannot write all possible serialize handlers users want. Therefore, I
would like to introduce user serialize handler.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #81080 — Yasuo Ohgaki — 2015-01-24T16:36:01+00:00

URL: https://externals.io/message/81065#81080 · In reply to: #81079

Hi all,



> However, once user serialize handler is implemented, overhead of user
> serialize handler is calling 2 PHP functions. i.e. serialize/unserialize
> functions whatever module provides. Users may compress/encrypt session data
> whatever methods also. If user wants serialize/compress/encrypt, 6 PHP
> functions calls are required. It would be reasonably fast. User serialize
> handler provides much freedom than now


I forgot about session_set_serialize_handler() call. So there is an
additional PHP function call.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net