Usability issue with LSAPI PHP

[jrmarino]

One php site that I have just showed up with blank pages and absolute zero errors in the log. I could not figure out what was going on with it.

I have LSAPI PHP 5.2.2 compiled.

So I get to the command line, and run the file in the command line using fastcgi PHP 5.2.1. No problem, the file executed perfectly.

Then I ran the same exact file with LSAPI PHP from the command line, and it brought up a bought of "can't start headers, output already started errors" immediately.

This was caused by extra white space in the config file after the closing "?>" bracket. This annoyance plagued PHP 4, but thankfully Zend fixed that problem for PHP 5. It ignores white space between the last closing bracket and EOF if there is no other characters present there.

So I have two major worries here:

1) Why is LSAPI PHP sensitive to trailing white space when CLI/CGI PHP is not?

2) Why did Litespeed return no output and not log any errors when the script was clearing outputting errors? I've seen similar behavior with litespeed when the fastcgi process died to a 500 server error. Is that is what is going on here?

 

[mistwang]

1) I think you need to turn output buffering in php.ini to avoid the "can't start headers, output already started errors". It really is the PHP internal, have thing to do with LSAPI, LSAPI just do what have been told by the PHP engine.

There is nothing to worry about response headers when running PHP from command. You can run LSAPI PHP from command line, should get the same result as the FCGI PHP.

2) Since the output header has been messed up, it would be difficult for the web server to interpret the response correctly. Due to the missing reply headers, part or whole reply body may be treated as response header, it is likely that the web page is broken in the browser.

 

[jrmarino]

You may have misunderstood the problem of number 1. I'm talking about the white space between the end of the script and the end of the file. for example:

<php

/* do stuff */

?>


(See this white space?  This is ignored by CLI/CGI PHP.  It is NOT ignored LSAPI PHP and it gets sent to stdout)
[EOF]

Both the fastcgi and lsapi PHP were compiled from the same source. The one thing that might explain this: fastcgi php looks at the php.ini in the default location. If lsapi does not, it could explain some of these differences.

2) I accept that litespeed may have interpreted the entire page as a header. I still don't know why an error was not logged. I'm also repeating: the output between lsapi PHP and fastcgi php running on the command line was not equal due to the differently handling of the trailing white space.


I can imagine some php.ini setting that handles trailing white space, but that means lsapi and fastcgi php are not using the same php.ini file.

 

[mistwang]

Whether to ignore the trailing white space is completely inside PHP engine, LSAPI has no control over it, like you said, it might be controled by a configuration in php.ini. You have to use the same php.ini when you compare the output of FCGI PHP and LSAPI PHP. Just use command line option "-c <path_to_ini_dir>".

If the error messages were not sent to STDERR stream, then it will be interpreted as the headers as well, otherwise, errors will show up in our error.log.

 

[jrmarino]

I ran "php -i" for both lsapi and fastcgi versions.

That confirms that both are using the exact same ini file (/opt/csw/etc/php.ini)

Yet they are behaving differently. That's just a fact -- you can tell me that they should not be, but that's not what I'm seeing.

When there is an error, lsphp will print it with the page (as it should). However in the particular case I'm telling you about, it did not.

I've also seen other examples where the php error was logged, so it's worked before.

 

[mistwang]

I could not reproduce this with a default FastCGI PHP 5.2.2 build with "./configure --enable-fastcgi", tried the php.ini-dist and php.ini-recommended come with the package.
test code: hello.php

<?php print   "hello,world"; ?>

Both leading and trialing space has not be removed when run it from command line. I am not sure what exactly will trigger FCGI PHP to ignore whitespaces. Do you have any idea? or have a working test case?