mezzio-session-ext vs php-ext-session

[pine3ree]

Feature Request

Q	A
New Features	yes
BC Break	maybe

Summary

This is more a comparison of behavior of mezzio-session-ext implementation vs the php ext-session.

1. calling session_start() via php-ext-session always sets a session-cookie in the first session-aware script's response even if no data is actually stored in the session. mezzio-session-ext only sets a response session-cookie if the session-data is changed or the session is regenerated. see (*)

2. php-ext-session sets the session-cookie in the response only if the session-id is changed either when the session is fresh (new) or its id is regenerated. mezzio-session-ext always sets the response session cookie if the session-data has been altered even if the session-id is unchanged. see (*)

3. php-ext-session always sends cache-limiters headers after a session_start() call. mezzio-session-ext only sends cache-limiters headers when the session-data ( or the session is regenerated) has been changed (*)

4. after calling session_start()(or session_regenerate_id()) the actual session id is available right away and may be used programmatically to identify the client browser session in the first fresh-session-generating script execution. With mezzio-session-ext in a fresh session or a regenerated session context the actual/final session-id is only available inside PhpSessionPersistence::persistSession() . see (**)

5. feature/maybe BC: php-ext-session does not set a new session-cookie (with same id) if we only change the session-cookie-lifetime. It would be useful to make mezzio-session-ext always send a new cooki when the session-lifetime is changed ($session->persistSessionFor()). This could be achieved allowing null to be returned in SessionCookiePersistenceInterface::getSessionLifetime(). A null value could be used to indicate that the cookie-lifetime has not been changed, any unsigned int to programmatically set the cookie-lifetime, 0 for restoring to a session-cookie.

6. BC renaming of SessionCookiePersistenceInterface methods
   we now have:

• SessionIdentifierAwareInterface::getID()
• SessionCookiePersistenceInterface::persistSessionFor(int $duration)
• SessionCookiePersistenceInterface::getSessionLifetime()

In my opinion we should have for consistency:

• SessionCookiePersistenceInterface::persistFor(int $duration)
• SessionCookiePersistenceInterface::getLifetime()

so that we can make calls call $session->getLifetime() and $session->persistFor(86400). The word 'Session' in the method seems redundant to me, same as $session->getSessionID() would seem.

(*) behaviours 1 and 2 (and 3) could be achieved in PhpSessionPersistence::persistSession() by comparing the initial session-id (from the request) with the final value and by calling PhpSessionPersistence::regenerateSession() even if only $id === '' or by triggering a $session = $session->regenerate() when $id === '' and then checking $session->isRegenerated(). (edited/added) We would also need to be able to distinguish when data changed or id has been regenerated, right now hasChanged() checks for both cases.

(**) behavior 3 could be achieved partially using a new SessionIsNewAwareInterface featuring an isNew() method. The new session id would be generated and set in the session instace along with a $isNew constructor param. But I haven not find a way to get the final id from the session instance after a regenerate() call in the inner handler. A SessionIsNewAwareInterface is the solution I have been adopted in my code, to both achieve fresh data-less session and session-id availability inside my handlers code. About that, php session books states that:

• Session support in PHP consists of a way to preserve certain data across subsequent accesses.
• A visitor accessing your web site is assigned a unique id, the so-called session id. (...)
• The session support allows you to store data between requests...

So php-ext-session always assigns a unique id and allows you to store data. I interpret this as 'data-less' an only 'client-identifying' session behavior

kind regards

related issue: #5

[kynx]

@pine3ree

after calling session_start()(or session_regenerate_id()) the actual session id is available right away and may be used programmatically to identify the client browser session in the first fresh-session-generating script execution. With mezzio-session-ext in a fresh session or a regenerated session context the actual/final session-id is only available inside PhpSessionPersistence::persistSession()

Doesn't $session->initializeId() do what you are looking for? I might have misunderstood, but that's what I use if I need the session id in code before the first response sent.

[pine3ree]

Hello @kynx,
yes but you'll have to call initializeId() programmatically, while the php-ext-session layer does it automatically. Wouldn't be better to let the persistence layer take care of it?
kind regards.

[pine3ree]

Hello @kynx,

even calling initializeId() programmatically...

//...
$session = $request->getAttribute('session');
$session->initializeId();
//...

will not set the response session cookie for unchanged session data. In my tests it continues to create new SIDs with data-less sessions. kind regards.