1

In the most simple code possible

<?php
    $ok = session_start();
    echo var_dump($ok);
?>

starting the session fails, $ok is false and no session cookie is created. Likewise, naming the session using session_name('xxx'); has no effect. The $_SESSION variable also doesn't persist values if set in another script.

Other legacy scripts on the same server that use the session feature work as expected. The same script works fine when run on localhost.

The steps I did during error analysis where:

  1. I removed naming the session and everything else to get the script above (bare minimum example reproduces the error).
  2. I checked the error log my provider offers, but no entry at all was found
  3. I made sure that no additional whitespace is present, and all scripts immediately start with session_start().
  4. In the same script I showed phpinfo() to mark that:
    1. Session Support: enabled
    2. session.auto_start: Off
    3. session.use_cookies: 1
    4. session.use_only_cookies: 1 (disputed, but since other scripts work...)
  5. I started doubting my sanity.
  6. I remembered running into "invisible characters" in form of byte-order-marks in text files before and figured, that maybe something like encoding might be a problem (see answer below) ...

What are additional sources for error that could cause these symptoms?

Jens
  • 6,275
  • 2
  • 25
  • 51
  • @mario Yes, that seems to be the same root cause as listed in your (quite impressive) writeup. I will add a link to the answer below. I will let it stand however, because I wasn't able to find that question given the typical search words. – Jens Jan 18 '19 at 14:12
  • I wouldn't want to dupe-close your question anyway. Albeit it just covers one (somewhat narrow) cause, the presentation clearly makes up for it. Though it might be even more useful if the answer covered the investigation steps again in more detail (php.ini checks, wget -S headers, error_reporting, finally the BOM discovery and fix). – mario Jan 18 '19 at 14:17
  • That's true, I tried to include the steps that didn't work in the question, and improved that in an edit now. – Jens Jan 18 '19 at 14:32

1 Answers1

1

The problem was, that the script files were encoded as what Notepad++ calls UTF-8 BOM under Windows.

enter image description here

Converting it to straight UTF-8 in Notepad++ and reuploading the scripts immediately fixed all problems.

So I guess that somewhere in the files a stray byte order mark was left that caused the php installation on the server to not recognize or fail to parse the script file.

Edit: The same root cause was described in much more detail by mario at https://stackoverflow.com/a/8028987/3055288

Jens
  • 6,275
  • 2
  • 25
  • 51
  • @mario Good question :-) Which level would you recommend for this type of error? – Jens Jan 18 '19 at 14:08
  • It's an E_WARNING, but `E_ALL` should be used nonetheless (in case it's caused/influenced by previous notices e.g.). – mario Jan 18 '19 at 14:11
  • Tried that with the failing script, by putting `error_reporting(E_ALL);` at the start, it didn't seem to do anything in regards to the messages in the log file. Maybe it also doesn't execute correctly, or its a matter of the server configuration (external host). – Jens Jan 18 '19 at 14:18
  • Log settings, `display_errors` or `set_error_handler` then. – mario Jan 18 '19 at 14:20
  • `display_errors` is indeed off, but I can't change php.ini (external host). Using `error_reporting()` to call a custom log function I was able to get `Cannot start session when headers already sent` which should have given at least a clue that something was going out before the session starts. Good point! I learned something as a php novice :-) – Jens Jan 18 '19 at 14:43