php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76724 Unable to start session when using PHP CGI
Submitted: 2018-08-09 07:21 UTC Modified: 2018-08-09 11:34 UTC
From: geral at braldesign dot com Assigned:
Status: Verified Package: Session related
PHP Version: 7.2.8 OS: CLOUDLINUX 6.10 standard
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: geral at braldesign dot com
New email:
PHP Version: OS:

 

 [2018-08-09 07:21 UTC] geral at braldesign dot com
Description:
------------
When executing the script with PHP CGI 7.2 and the flag "-q" it will generate one warning. When not using thr flag it works as expected.

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

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

session_start();

Expected result:
----------------
no warning nor errors.

Actual result:
--------------
<b>Warning</b>:  session_start(): Cannot start session when headers already sent in ... on line <b>7</b>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-08-09 09:14 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2018-08-09 09:14 UTC] requinix@php.net
-q deliberately makes the scripting engine think that headers have been sent, but it's been that way for so long that I can't say exactly why it does so. I can only assume there is/was a good reason.
 [2018-08-09 09:17 UTC] geral at braldesign dot com
Then, there is no way to use a session with a quiet script? thanks.
 [2018-08-09 09:19 UTC] requinix@php.net
Well, without knowing what you're doing or why, I would suggest using the regular PHP binary instead of php-cgi.
 [2018-08-09 09:24 UTC] geral at braldesign dot com
I'm using the php-cli only because it is the default used by cron jobs and i'm using session on it just because the script uses session to store data for the execution.
If this behavior is intended I can only work around it.
Thanks for the explanation.
 [2018-08-09 09:28 UTC] spam2 at rhsoft dot net
a proper software runtime skips session_start() when not running within a webserver environment, these are a few lines of PHP code and be it only to prevent spit session files to disk for no gain
 [2018-08-09 09:30 UTC] requinix@php.net
php-cli should be used for cronjobs, yes, but this bug report is about php-cgi. They are not the same.
Either you are using php-cli and this bug is irrelevant, or you are using php-cgi and you should not be.

And you know sessions don't really work from the command line, right? You would have to force a particular session ID, new or existing, for sessions to work across multiple runs.
 [2018-08-09 09:54 UTC] geral at braldesign dot com
I was retesting everything, so my server provider uses cgi-fcgi to execute cronjobs, to test this I just echo php_sapi_name() on an empty script executed by cronjob.
I'm only using sessions because the backoffice uses it, i'm only using it as global variables.
 [2018-08-09 09:56 UTC] spam2 at rhsoft dot net
if you provider is using cgi-fcgi instead of /usr/bin/php for cronjobs he is a fool becaus ethat breaks the usual way such code looks like

if(PHP_SAPI !== 'cli')
{
 session_start();
}
 [2018-08-09 10:01 UTC] geral at braldesign dot com
The /usr/bin/php is the cgi version :

# /usr/bin/php -v
PHP 7.2.8 (cgi-fcgi) (built: Jul 19 2018 09:57:11)

Apparently this is setup like this as deployed by CloudLinux service, should I contact them about this?
 [2018-08-09 11:34 UTC] cmb@php.net
In the olden days there was no CLI SAPI.  Instead the CGI
executable could be used, and -q (which is --no-headers) served to
make it more useful for the command line.  For better
compatibility with the CLI SAPI, we might consider to “fix” it[1].
OTOH, perhaps we should rid the -q option of the CGI SAPI
altogether?

Anyhow, the following workaround might be sufficient in this case:

  php -q -d session.use_cookies=0 -d session.cache_limiter="" <file>

[1] <https://github.com/php/php-src/blob/php-7.3.0beta1/sapi/cgi/cgi_main.c#L2420>
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Oct 16 15:01:25 2018 UTC