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

  100065
July 27, 2017 17:03 lists@rhsoft.net ("lists@rhsoft.net")
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
___________________________________


    
  100080
July 28, 2017 12:48 rowan.collins@gmail.com (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.) 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]
  100082
July 28, 2017 13:37 lists@rhsoft.net ("lists@rhsoft.net")
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
  100083
July 28, 2017 14:11 rowan.collins@gmail.com (Rowan Collins)
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]
  100084
July 28, 2017 14:45 pollita@php.net (Sara Golemon)
On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins 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
  100085
July 28, 2017 14:48 narf@devilix.net (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!
  100086
July 28, 2017 15:03 lists@rhsoft.net ("lists@rhsoft.net")
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 :-)