Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » session_start() should not reset $_SESSIOn if it's not empty »

session_start() should not reset $_SESSIOn if it's not empty

php.internals

lists@rhsoft.net

9 years ago
currently i try to optimize our system so that the landing-page if it does not contain forms and when no user is logged in could be cached with APCu which works fine so far there is still a early session_start(); and while delay that would be probably possible like it's happening currently with database connection on-demand but there are some important things written in $_SESSION which i can't delay and the sample below shows that they would get lost in case it's not a cache hit ___________________________________ <?php declare(strict_types=1); if(!empty($_SESSION['test'])) { echo $_SESSION['test']; } $_SESSION['test'] = 'test'; session_start(); ___________________________________ if that could work in the way that session_start() keeps the current state of $_SESSION if not empty it would be possible to put the APCU-Read and if exit($apcu_content); before session_start() which would gain another 30% performance

Rowan Collins

9 years ago
On 27 July 2017 18:03:23 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
>if that could work in the way that session_start() keeps the current >state of $_SESSION if not empty it would be possible to put the >APCU-Read and if exit($apcu_content); before session_start() which >would >gain another 30% performance
I think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (Arguably, all the other superglobals should be read only for the same reason, but that would be a huge break now.) If I understand you right, the scenario you describe is "I don't want to start a session yet, but if and when I do, I want to put this data into it". It feels like that could be adequately handled in userland with a wrapper object (or global var and functions if you prefer), which reads to and from $_SESSION when a session is open, but a a holding array when it's not yet. Regards,
-- Rowan Collins [IMSoP]

lists@rhsoft.net

9 years ago
Am 28.07.2017 um 14:48 schrieb Rowan Collins:
> On 27 July 2017 18:03:23 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote: >> if that could work in the way that session_start() keeps the current >> state of $_SESSION if not empty it would be possible to put the >> APCU-Read and if exit($apcu_content); before session_start() which >> would >> gain another 30% performance > > I think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (Arguably, all the other superglobals should be read only for the same reason, but that would be a huge break now.)
make them readonly would break my whole codebase including autotests and code-coverage tools because it is legit to as example fill $_SERVER['SERVER_NAME'] with specific informations to define a straight behavior when running in cli-test-mode instead wrap every basic thing in function calls - at the curretn state a core-cms cache-hit has a total of 32 funtion calls including PHP internal ones hence that 3 bugreport are becoming a MAJOR PROBLEM because the system itself is so fast that under load after a short time you get problems with dattabase connections and with persistent connections because of the third one after the load is gone any strict-typed application jsut breaks horrible https://bugs.php.net/bug.php?id=74971 https://bugs.php.net/bug.php?id=74970 https://bugs.php.net/bug.php?id=74967
> If I understand you right, the scenario you describe is "I don't want to start a session yet, but if and when I do, I want to put this data into it". It feels like that could be adequately handled in userland with a wrapper object (or global var and functions if you prefer), which reads to and from $_SESSION when a session is open, but a a holding array when it's not yet.
that don't work because at this point you don't know in userland if you started a completly new session which should be initialized with values for follow-up requests or use the existing values from a previous request - at least not without writing ugly code session_start() knows that and would only need a flag if it is desired to bail out as you said above or as for this case init the session with specific values

Rowan Collins

9 years ago
On 28 July 2017 14:37:10 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
>(Arguably, all the other superglobals should be read only for the same >reason, but that would be a huge break now.) > >make them readonly would break my whole codebase
Yes, I only meant that as an absolutely hypothetical "if I had a time machine and could design it a different way...", I realise it would break everything to change it now.
>> If I understand you right, the scenario you describe is "I don't want >to start a session yet, but if and when I do, I want to put this data >into it". It feels like that could be adequately handled in userland >with a wrapper object (or global var and functions if you prefer), >which reads to and from $_SESSION when a session is open, but a a >holding array when it's not yet. > >that don't work because at this point you don't know in userland if you >started a completly new session which should be initialized with values >for follow-up requests or use the existing values from a previous >request - at least not without writing ugly code
Do you mean like this? session_start(); if ( ! $_SESSION['initialised'] ) { $_SESSION['initialised'] = true; foreach ( $this->session_init_vars as $var => $val ) { $_SESSION[ $var ] = $val; } } That should work as long as you don't run session_start() outside that function, and centralising that is already necessary to avoid "already started" errors. Regards,
-- Rowan Collins [IMSoP]

Sara Golemon

9 years ago
On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 28 July 2017 14:37:10 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote: >>(Arguably, all the other superglobals should be read only for the same >>reason, but that would be a huge break now.) >> >>make them readonly would break my whole codebase > > Yes, I only meant that as an absolutely hypothetical "if I had a time machine and could design it a different way...", I realise it would break everything to change it now. > >
ftr; I'd vote in favor of several BC breaking things to do with autoglobals, among them: * Make them objects (though ArrayAccess based for less hostile BC breakage) * Make most of them read-only (offsetGet(), but no offsetSet) * Make $_SESSION[...] access produce an error or auto-start the session I've seen too many codebases abuse GPCER vars as a generic storage location because "globals are bad, but this is good because it doesn't include the word global". As a performance issue, the runtime has to assume autoglobals are inherently volatile and could change on a whim at any moment (much like $http_response_headers). Restricting their mutability would be a win. The request globals could probably also be optimized fairly significantly. If anyone agrees, I'm willing to RFC it. If not, I'll continue living with it. :D -Sara

Andrey Andreev

9 years ago
Hi, On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <pollita@php.net> wrote:
> > ftr; I'd vote in favor of several BC breaking things to do with > autoglobals, among them: > > * Make them objects (though ArrayAccess based for less hostile BC breakage) > * Make most of them read-only (offsetGet(), but no offsetSet) > * Make $_SESSION[...] access produce an error or auto-start the session > > I've seen too many codebases abuse GPCER vars as a generic storage > location because "globals are bad, but this is good because it doesn't > include the word global". As a performance issue, the runtime has to > assume autoglobals are inherently volatile and could change on a whim > at any moment (much like $http_response_headers). Restricting their > mutability would be a win. The request globals could probably also be > optimized fairly significantly. > > If anyone agrees, I'm willing to RFC it. If not, I'll continue living > with it. :D >
Yes, please!

lists@rhsoft.net

9 years ago
Am 28.07.2017 um 16:48 schrieb Andrey Andreev:
> Hi, > > On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <pollita@php.net> wrote: >> >> ftr; I'd vote in favor of several BC breaking things to do with >> autoglobals, among them: >> >> * Make them objects (though ArrayAccess based for less hostile BC breakage) >> * Make most of them read-only (offsetGet(), but no offsetSet) >> * Make $_SESSION[...] access produce an error or auto-start the session >> >> I've seen too many codebases abuse GPCER vars as a generic storage >> location because "globals are bad, but this is good because it doesn't >> include the word global". As a performance issue, the runtime has to >> assume autoglobals are inherently volatile and could change on a whim >> at any moment (much like $http_response_headers). Restricting their >> mutability would be a win. The request globals could probably also be >> optimized fairly significantly. >> >> If anyone agrees, I'm willing to RFC it. If not, I'll continue living >> with it. :D >> > > Yes, please!
raise a warning when write to $_SESSION without a session_start() make a implicit autostart - *for sure not* this would only produce hidden errors or later warnings when you rely on session params and introduce more problems that it solves because clients don't like the same cookies ith different params make POST/GET/SERVER readonly - only when you refactor a 250000 line code base as well as deplyed code which relies on the framework did the right thing with them previously :-)