Send a blank email to [email protected] to get a copy of this message
>>> It is not broken functionally, indeed.>>> It's broken by design - if I write session_start(), options or not, I >>> would never expect it to immediately close the session. It's highly >>> misleading and this will lead to a lot of abuse.>>>>>> I don't want to confuse users.>> Better name would be appreciated.>>>> Perhaps, "close" may be better option name.>>>> session_start(['read_only'=>true]);>> ↓>> session_start(['close']=>true);>>>> Any comments/better names? >>I'd rather suggest this to be a separate function and not an option for session_start().
>I've got this coverered in a draft RFC that I will announce for discussion later today.
Hi Andrey,
referring to your comments above and the related content at https://wiki.php.net/rfc/session-read_only-lazy_write,
your example problem use-case/result -
// $_SESSION['logged_in'] has been set in a previous request
Request 1: session_start(['read_only' => TRUE]);
Request 2: session_start(); unset($_SESSION['logged_in']); session_write_close();
Request 1: if ($_SESSION['logged_in']) { /* logic */ } // evaluates to TRUE
works the same way today that you describe as a problem, if I'm not mistaken.
- Request 1 locks the session and Request 2 waits.
- Request 1 finishes and unlocks the session.
- Request 2 can now get on with its work.
I initially suggested this "read_only" feature to Yasuo (as he has implemented it today)
in order to solve this blocking wait time problem. The use case I wanted a solution
for is common in the applications I design/work-on/see today which is modular AJAXy/independent
access to PHP sessions, i.e. "is this user logged in and allowed to call this thing?"
In these use cases I often know I just need to read the session data and will not write to it
therefore I just want the lightest, quickest read-and-release-session process possible for
near-concurrent access to reading the session. Actually writing+reading to a session (or any
datastore for that matter) becomes a synchronicity issue which is fundamentally at odds
with a codebase designed around asynchronous access to state and needs to be solved for by the
application architecture/design in those situations that need to have that sort of
protection. In other words, I believe the example problem use case you've posed is an
application design problem not a language level issue IMO.
On a related note, your suggestion of a "true read only" implementation would presumably
either throw an error on attempt to write to a session that was locked as "read only" or
would act as sessions act today, which is to say, wait for the session to unlock before writing to
it. My gut reaction is that neither of these are better than what we have today but
the conversation is young and I'm interested to hear more.
One last point, the ability to "configure" a session through an array of options is very
useful from an end-user code design point-of-view. Moving the ability to start a session as read
only to a separate function call than I would use to start a session otherwise forces choices in
code design that can otherwise be much more elegantly handled through the use
of a single function with a configuration parameter.
Best,
Bill Salak