Remote host header already sent warning, but not on localhost

I’m experiencing a very strange problem with my php scriptie. I’ve been working on this little scriptie and all was fine until three weeks ago. Now it generates a header warning on the remote server, but strangely not on my test server.

  • I wrote up another little scriptie (see below) to test the header and make sure it was not the server. Same result: remote generates a warning and local does not.
  • I tested just the header in a php redirect file and this works correctly on remote host.

I’ve posted elsewhere (I know, I should have brought it here first :wink: and went through the full broadsides of comments warning me to eliminate any, all, every, not a one, preceding space before the header function. This did not fix the problem, and if the script works without error on my localhost then, QED, its not in my file, per se…cuz bad code with spaces is bad code wherever you put it. haha

This leaves me with few ideas of how to go forward. One thought is try to cause my localhost to repeat the problem. I was adding a magic_quotes scriptie when I got the flat tire, so I turned it on in my localhost setup to no effect.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<?php
	var_dump($submitted = isset($_POST['submitted']) ? 
		$_POST['submitted'] : 
		NULL);
	if ($submitted) {
		header ('Location: menu_edit.php?added=1');
		print 'This is wrong!';
	} else {
			print 'Waiting...';
	}
?>
	<form method="post" action="<?php $_SERVER['PHP_SELF'] ?>">
	<input type="submit" value="Submit" name="submitted" />
</body>
</html>

Now, just moving the php to the top is not enough. I was working with a fellow in the other thread. We tried this next version. (NOTE: As I’m posting this I also rechecked the code to be sure I had the right version. Originally we believed he found a solution; however, as I recheck the file it is not working on the remote host and is working on localhost. Also, I decided to leave the other thread, cuz I don’t agree with the the fellow’s conclusion ignoring the fact my script, above, works on my localhost. Its not personal. I just need to resolve this problem :slight_smile:

<?php
var_dump($submitted = isset($_POST['submitted']) ? $_POST['submitted'] : NULL);
if ($submitted) {
header('Location:menu_edit.php?added=1');
} else {
print 'Waiting for you.......';
}
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
	<form method="post" action="<?php $_SERVER['PHP_SELF'] ?>">
	<input type="submit" value="Submit" name="submitted" />
	</form>
</body>
</html>

And if that wasn’t enough…I set this up on two remote hosting services. Both recreated the error. Maybe the answer is about these bare bones shared hosting setups? I loaded my server using YUM install. I also have not updated it since install in November. Maybe there was an update to some server plugin during these last four or five weeks?

If I can’t get an answer to this problem, I’m going to contact php.net and demand a refund!

I doubt you had the same experience. X

Fix the source of the problem? :wink:

Seriously - I’ve never found a situation where I’ve HAD to use output buffering to fix a problem; there’s almost always a way to rewrite code to remove the necessity.

I understand the author declares the encoding in the meta tag for the file. But can someone explain that last bit about the server header?

The server sends a header before the file, imagine me saying “german: guten tag” vs “english: good day”. Sending a meta tag as well is the equivalent of “german: (oops, I meant english) - good day”. This can work (not sure on all browsers) because in theory everything before the <meta is universal (there should be no characters that can be misrepresented), so the browser should be capable of switching modes when it encounters that ‘oops’.

Basically, delete the meta tag, check what your server is sending, put the meta tag back to match that, and make sure your text editor is also saving in the same format. Or, change the server to match the text editor (and meta tag).

Hmmm… so I made it worse. Is there a better solution?

Just had the same problem, thats why I ended up here.

putting the following line in a .htaccess did the trick for me:
php_flag output_buffering on

Thanx to ScallioXTX

That’s called hiding the problem - the problem is still there as you haven’t fixed it, just hidden it away along with lots of other potential problems that you will now never know about and which might destroy your site.

With properly written PHP that flag should never need to be on.

I suspect the local host has output_buffering set to On or a numeric value in php.ini, while the remote hosts have this set to 0 (zero) or Off.

I like the way you’re thinking.
I removed the meta tag from the file, loaded the above pages, and viewed source. Nothing there to see before the opening <!DOCTYPE>. I even removed that leaving just <html>. There was no visible character before the first page tag.

Mozilla shows the doctype as iso-8859-1. The other thing to do with this test is try to provide a positive result. Then what is the meta declaration for utf-8 with a BOM?
Chris

PS, Is it even possible to have PHP (and I guess some set up of the LAMP server) where Header() performs a redirect even though it is technically incorrect? If yes (as seems to be the case with my LAMP set up) then what would be the purpose?

That first piece of code should always generate a hearers already sent error if the header call is executed because the headers have to be sent before the < on the front of the doctype.

So if it isn’t giving that error then the condition to call the header() isn’t being met.

I like the way you’re thinking.

lol you shouldn’t. I skimmed this, my bad, looked like an unresolved qn so I answered the last post.

The problem is that you are using var_dump() before a header call. var_dump typically outputs stuff, even if this is just ‘null’, so the problem becomes why is your local host not behaving correctly - the remotes are doing what I would expect, logic_earth had this nailed in post 2.

The only place I found any reference to this error was at Wikipedia

Be warned. I’ve been messing with this error since July 7th. My shared hosting service refused to acknowledge my site’s code was working before this date and investigate any changes to their set up. I don’t know why but they also have a forum in addition to traditional trouble tickets, and suggested I use their forum to ask for help instead:mad: A second shared hosting service I signed up for also had the same set up (no forum :rolleyes:

Hey, Sitepoint. What took you so long! haha!
Xtian

What I can tell you are my observations, carefully and faithfully presented as the facts of this problem. I would hope someone tries this code on their own server and verifies, or disputes my results. :slight_smile:

Chris

PS. In the case someone tries this on their server, let me remind you to also change the location’s URL to something that won’t itself return an error.

Yes. In browser and in an error_log file.

Does your local server have php setup to display errors?

I’ve been investigating the possibility of BOM in the file as mentioned in my previous post and in other troubleshooting resources. And I found a sitepoint discussion about the BOM from last November. In this the discussion has two points I’d like to mention.

First, there is the suggestion a file can be examined with VIM to look for the BOM characters:

all *nix servers are guaranteed to have (n)vi(m) that the author could use via ssh.
. And that’s just what I did. On one server I examined my code with VIM via SSH and found nothing before my code. On the other server I used cPanel’s text editor which has character encoding identification and a menu to select the correct encoding. Back to the same problem.

Second, the is mention of the server making a declaration of the file’s encoding,

This is still an authoring error. If the server declares an encoding other than utf-8, then the author should either change the document encoding, or change the server header.

I understand the author declares the encoding in the meta tag for the file. But can someone explain that last bit about the server header?

Chris