Bug #78629 [Opn]: session_start() behaviour when cookie does NOT need to be set incorrect

From: Date: Thu, 03 Oct 2019 12:43:24 +0000
Subject: Bug #78629 [Opn]: session_start() behaviour when cookie does NOT need to be set incorrect
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223023@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78629&edit=1

 ID:                 78629
 User updated by:    james at gogo dot co dot nz
 Reported by:        james at gogo dot co dot nz
 Summary:            session_start() behaviour when cookie does NOT need
                     to be set incorrect
 Status:             Open
 Type:               Bug
 Package:            Session related
 Operating System:   Ubuntu 18.04
 PHP Version:        7.1.32+
 Block user comment: N
 Private report:     N

 New Comment:

NB1: yes uniqid for a session id is not good, this is just a simple testcase.  
NB2: session.use_strict_mode is off where available


Previous Comments:
------------------------------------------------------------------------
[2019-10-03 12:30:54] james at gogo dot co dot nz

I tested further and the testcase given passes (value increments as expected) for
7.0.33-11+ubuntu18.04.1+deb.sury.org+1 and below, 7.1.32-1+ubuntu18.04.1+deb.sury.org+1 and above
fail (value does not increment).

------------------------------------------------------------------------
[2019-10-03 11:45:28] james at gogo dot co dot nz

Description:
------------
In PHP 7.2 (I believe) session_start() was modified with regard to it's abilities after headers
had been sent.

It was stated regarding the changes (https://externals.io/message/96387) that "it changes
behavior only when there is useless session which is fatal anyway", this is not the case.

In versions, at least in up to 5.6, if the browser sent OR if before output you explicitly and
manually set the session_id() cookie then you could successfully and normally (save for
notice/warning) session_start() after output and that $_SESSION would be perfectly functional and
indeed get written back quite normally.

I can not speak for others, but I routinely used this method successfully through the last decade in
order to delay session starting as long as possible (if at all) to reduce lock contention.

session_start() prior 7.2 allowed one to set just the cookie themselves prior output and start
session successfully using that cookie after output, 7.2 forward does not.


Test script:
---------------
<?php

 if(!isset($_COOKIE[session_name()]))
 {
   session_id(uniqid('session-'));
   setcookie(session_name(), session_id(), 0, '/');
 }

 header('Content-Type: text/plain');
 echo "PHP Version: " . phpversion() . "\n";
 echo str_repeat('              ', 1024); flush(); // ensure output is flushed
 echo "Headers Sent Before session_start(): " . (headers_sent() ? 'Y':
'N') . "\n";

 @session_start();

 echo "Incrementing session variable (should increment each reload): " .
($_SESSION['testvar'] ? $_SESSION['testvar'] : 0) . "\n";
 $_SESSION['testvar'] += 1;

?>


Expected result:
----------------
The value for "Incrementing session variable" should increase on each reload (PHP 5.6
below)

Actual result:
--------------
The value for "Incrementing session variable" remains 0 (PHP 7.2 above)


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=78629&edit=1


Thread (4 messages)

« previous php.bugs (#223023) next »