|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81025 Session deserialization does not handle UTF-8 BOM
Submitted: 2021-05-09 22:11 UTC Modified: 2021-05-09 22:24 UTC
From: Parkhideh at att dot net Assigned:
Status: Not a bug Package: Built-in web server
PHP Version: 7.4.19 OS: Windows 10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: Parkhideh at att dot net
New email:
PHP Version: OS:


 [2021-05-09 22:11 UTC] Parkhideh at att dot net
From manual page:
I read many comments about why a session_start() does not connect.
Luckily one of my 8 lines test program did work.  The difference was the non-working php file was saved as "UTF-8 with BOM" that made every thing else work but session_start().

Note that on the local PortableApps xampp with php 8.0.3 under Windows 10 session_start() connects correctly.  On host with php 7.4 and 8.05 this problem shows.

Frankly I did not know that UTF-8 had a BOM option till now!!  Unicode claims it doesn't, Windows 10 does it anyway.

Test script:
Setup php file:
$_SESSION['keyword'] = 1916; 
$_SESSION['driverVer'] = "1.1.1";
$CrLf = "\r\n";
echo "<br>PHP version is " . phpversion() . $CrLf;

Run file showing the error:
$q = $_SESSION['keyword']; 
$v = $_SESSION['driverVer'];
$CrLf = "\r\n";
echo "<br>-- $q -- $v -- , PHP version is " . phpversion() . $CrLf;

Expected result:
If the second file is saved as "UTF-8 with BOM"; then on some systems it will generate an error message.  Note that the same file saved as UTF-8 is a few bytes smaller, but both will pass the compare text test.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-05-09 22:14 UTC]
-Summary: php 8.0.5 +Summary: Session deserialization does not handle UTF-8 BOM
 [2021-05-09 22:14 UTC] fgfgfg dot hjhjhjhj at ghghgh dot fg
don't use BOM - well known fact for 15 years at least
 [2021-05-09 22:24 UTC]
-Status: Open +Status: Not a bug
 [2021-05-09 22:24 UTC]
UTF-8 has a BOM defined because multibyte encodings try to define one (in case some readers need that information) but even the standard recommends not using it.

If you save with the BOM then that adds three bytes before the opening <?php, which PHP will use to begin output, which means functions like session_start() and header() that require executing before output has begun will not work.

If you had error logging set up properly for your environment then you would have seen a warning from PHP about this happening.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Feb 25 12:01:27 2024 UTC