PDA

View Full Version : Warning: Cannot add header information - headers already sent

tcjay
1-6-02, 04:13 AM
Warning: Cannot add header information - headers already sent by (output started at /www/e/epilepsybra2/htdocs/sslinks/global.inc.php:2) in /www/e/epilepsybra2/htdocs/sslinks/global.inc.php on line 582

I receive this message frequently when installing php scripts and everytime it seems to relate to a line such as

header("Location: links.php")

what causes this and how do I go about fixing it.

TIA

Tom :)
PSteele
1-6-02, 08:40 AM
You've already sent output to the client, and then you're using the "Location" header to try and redirect the client. But, since you've already started sending output to the client, you get that error.

You need to either:

a) Make sure there is *NO* code outside scripting blocks before setting the "Location" header

- or -

b) I think I read that PHP has a way to turn on output buffering so nothing is sent to the client until the entire page is complete. That way, you could process an entire page and then at the bottom, send the "Location" header to redirect the client somewhere else.
tcjay
1-6-02, 01:32 PM
How do I tell if there is script outside the script blocks. You lost me there.
tcjay
1-6-02, 01:32 PM
How do I tell if there is script outside the script blocks.
PSteele
1-6-02, 06:29 PM
Here's a short example:

--------------------------------------------
<html>
<head>
<?php
header("Location: http://www.php.net/");
?>
--------------------------------------------

This fails because I've already sent data to the client (the starting HTML and HEAD tags). Here's another example that will fail:

--------------------------------------------
<?php
$name = "bob";
$age = 22;
?>php

<?php
header("Location: http://www.php.net/");
?>
--------------------------------------------

This fails because between the two script blocks, there's that blank line. Anything *IN* a script block is server-side script and processed on the server. As soon as the webserver sees something *outside* of the script blocks, it knows it's intended for the client and sends it out.

Whenever you decide to send the "Location" header, make sure it's done before any code can be sent to the client.

Does that clear things up?
jtucker135
1-18-02, 11:59 AM
This is precisely the problem caused by the !#usr/local/bin/php line. tcjay, the programmer, *must* output to the client (the line !#usr/local/bin/php even if "quieted" with -q).

PLEASE PLEASE PLEASE correct me if I'm wrong but neither PHP cookies, nor session variables, nor header() works on the current powweb implementation of CGI/PHP.

Does anyone know if the siteops intend to correct this or not?
Does anyone have a workaround?
Does anyone have an implementation of any of these three functions that works at powweb?
jtucker135
1-18-02, 11:40 PM
OK!! I've been a good bug tester and have found the most likely solution. This was a known problem with CGI/PHP. Fortunately it's been corrected with output_buffering.

Currently, POWWEB has output_buffering turned OFF and it needs to be turned ON. This can only be done by administrators with access to the PHP.ini file.
Starr
1-18-02, 11:48 PM
You can create and use your own php.ini. Powweb will not do this for you.
jtucker135
1-18-02, 11:59 PM
Thanks Starr.

Since there are no instructions in the FAQ, I'm assuming my php.ini goes in /etc ?

Can you tell me when it gets read?
jtucker135
1-19-02, 12:53 AM
phpinfo(); says the following:

Configuration File (php.ini) Path /usr/local/lib/php.ini

This means in order to set the path to my own php.ini I need access to a file I can't get. :) How do I remedy this?

Can tech support change my PHP configuration file path to point to /etc/php.ini ?

Can you help me?
jtucker135
1-19-02, 01:06 AM
The php3.ini file
The php3.ini file is read when PHP's parser starts up. For the server module versions of PHP, this happens only once when the web server is started. For the CGI version, it happens on every invocation.
hotrats
1-20-02, 03:55 AM
You can create and use your own php.ini. Powweb will not do this for you.

I've been watching these threads with interest. Stayed out since it seemed to be going in a direction. Now there is a direction but possibly we have less information than we need to achieve a result? I would like to see output_buffering turned on also ... please. There are work arounds for scripts but without output_buffering turned on the problem is immense if not impossible.

hotrats
hotrats
1-20-02, 12:09 PM
Found a work-around to my problem.

Actually I got caught up in the output_buffering issue and missed the trees for the forest. The code I was having an issue with just needed some TLC and a bit of adjusting ... output_buffering had nothing whatsoever to do with my issue.

Thanks for listening!