Problem with PHP - FastCGI - Headers
-
If your HTML or PHP has any whitespace before the opening
<?phptag,header()will fail to do what you expect. Quoting the PHP manual:Remember that header() must be called before any actual output is sent, either by normal HTML tags,
blank lines in a file, or from PHP. It is a very common error to read code with include(), or require(),
functions, or another file access function, and have spaces or empty lines that are output before header()
is called. The same problem exists when using a single PHP/HTML file.Cheers, Peter (bitten by this more than once!)
Software rusts. Simon Stephenson, ca 1994.
Hi Peter, Thank you for your response. I have double-checked and there is no output (not even whitespace) above. The test script is working fine on other web servers, but is failing on just this one. I cannot make any sense of it. And there are no errors being logged on the server. It is a shared hosting Linux package with FastHosts (if this makes any difference). Many thanks, Lea
-
Hi Peter, Thank you for your response. I have double-checked and there is no output (not even whitespace) above. The test script is working fine on other web servers, but is failing on just this one. I cannot make any sense of it. And there are no errors being logged on the server. It is a shared hosting Linux package with FastHosts (if this makes any difference). Many thanks, Lea
If it works on one server but not another, it smells like a server config is contributing to the problem. I suggest you put one or more
echo('x')statements in strategic places and use something like WireShark to see exactly what the server is returning. You should be able to spot the difference between good and bad servers pretty quickly. Cheers, PeterSoftware rusts. Simon Stephenson, ca 1994.
-
If it works on one server but not another, it smells like a server config is contributing to the problem. I suggest you put one or more
echo('x')statements in strategic places and use something like WireShark to see exactly what the server is returning. You should be able to spot the difference between good and bad servers pretty quickly. Cheers, PeterSoftware rusts. Simon Stephenson, ca 1994.
It seems to be the very first call to header that fails. It fails even if I stick an echo before it (and echoed text is not displayed). If I used
echo 'x'; die;it displays x, but obviously doesn't attempt to change headers. Do you know if there are required permissions to use header function? Thanks again -
It seems to be the very first call to header that fails. It fails even if I stick an echo before it (and echoed text is not displayed). If I used
echo 'x'; die;it displays x, but obviously doesn't attempt to change headers. Do you know if there are required permissions to use header function? Thanks againlhayes00 wrote:
It fails even if I stick an echo before it (and echoed text is not displayed).
Aha! If the echoed text is not displayed for an echo() BEFORE the first header(), then it seems that code is not being entered. An echo() should output something recognisable, even if the total result is a mangled chunk of HTML. This also ties in with the ERR_EMPTY_RESPONSE you mentioned in your original question. The next place I would go looking is Apache and PHP version differences between the working and failing sites. AFAIK, there are no special permissions required to use header(). ie, from a permissions point of view, header() is as good or bad as echo(). Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
lhayes00 wrote:
It fails even if I stick an echo before it (and echoed text is not displayed).
Aha! If the echoed text is not displayed for an echo() BEFORE the first header(), then it seems that code is not being entered. An echo() should output something recognisable, even if the total result is a mangled chunk of HTML. This also ties in with the ERR_EMPTY_RESPONSE you mentioned in your original question. The next place I would go looking is Apache and PHP version differences between the working and failing sites. AFAIK, there are no special permissions required to use header(). ie, from a permissions point of view, header() is as good or bad as echo(). Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
The working server is using PHP 5.2.17 / The non-working is using PHP 5.2.6. They are both running CGI/FastCGI. Apart from that, phpinfo() shows basically the same thing for both. Many thanks,
Sorry, I may have confused you with my last reply. Should have put in dot points? :-O 1. The first thing to look for is why the first echo() doesn't. 2. If you got nowhere looking for that, then look for differences between the servers (which now appear to be irrelevant.) Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
Sorry, I may have confused you with my last reply. Should have put in dot points? :-O 1. The first thing to look for is why the first echo() doesn't. 2. If you got nowhere looking for that, then look for differences between the servers (which now appear to be irrelevant.) Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
I have the same problem with no error output and I just receive a white screen. I have to check the apache error log. On my system the path is /var/log/apache2/error.log
-
I have the same problem with no error output and I just receive a white screen. I have to check the apache error log. On my system the path is /var/log/apache2/error.log
The error log doesn't show any related errors. The access log shows the following (I called the test file t404.php): [05/Feb/2011:00:59:51 +0000] 92.232.71.252 - - "GET /t404.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.84 Safari/534.13" This indicates that the header status is being changed, but for some reason the content is not being presented to end-user. The following code is still producing blank output in Chrome, but it IS creating the "test.txt" file with the contents 'Hello World!'. So this indicates that the script is in fact being executed.
This doesn't make any sense at all to me...
-
The error log doesn't show any related errors. The access log shows the following (I called the test file t404.php): [05/Feb/2011:00:59:51 +0000] 92.232.71.252 - - "GET /t404.php HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.84 Safari/534.13" This indicates that the header status is being changed, but for some reason the content is not being presented to end-user. The following code is still producing blank output in Chrome, but it IS creating the "test.txt" file with the contents 'Hello World!'. So this indicates that the script is in fact being executed.
This doesn't make any sense at all to me...
theres some good stuff http://php.net/manual/en/function.header.php about Chrome requiring a status header before changing headers.