Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

Posted by [email protected] 
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 27 July 2017 18:03:23 BST, "[email protected]" <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 28.07.2017 um 14:48 schrieb Rowan Collins:
> On 27 July 2017 18:03:23 BST, "[email protected]" <[email protected]> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 28 July 2017 14:37:10 BST, "[email protected]" <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Jul 28, 2017 at 10:11 AM, Rowan Collins <[email protected]> wrote:
> On 28 July 2017 14:37:10 BST, "[email protected]" <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,

On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <[email protected]> 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!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 28.07.2017 um 16:48 schrieb Andrey Andreev:
> Hi,
>
> On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon <[email protected]> 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 :-)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login