0

I have the classical Symphony flash message implementation:

$_SESSION['flash'] = "This is a flash message";
header('location: index.php');

It works fine on two different servers but has a strange behavior on a third one, a hosted server, LAMP stack, of which configuration I'm not aware about in detail. On the third server the script execution brings up first a warning - that the headers have already been sent ... (but I didn't output anything, on the other servers it works) - then if I trigger again the redirecting event, a hyperlink, it brings me into the index.php file with the message rendered. I know how to make it "portable", by using JavaScript to redirect, but I wonder what is the cause of this behavior. I suspect a server configuration for a PHP or Apache module. Thanks for your hand!

ajreal
  • 46,720
  • 11
  • 89
  • 119
Ginger Opariti
  • 1,282
  • 5
  • 23
  • 41
  • 1
    This really has little to do with the excerpted code. Some part of the code this is running within is different on the third server. Look into where it states the headers were already sent, it should give you a line number. – ceejayoz Dec 08 '11 at 18:03
  • **Exactly** what is written above these 2 lines ? – Manse Dec 08 '11 at 18:04
  • Well what changes did you make to the files before you put the script on the new server? Can you please show us the code that comes before the block you have put in the question? – Ryan Dec 08 '11 at 18:05
  • possible duplicate of [Headers already sent by PHP](http://stackoverflow.com/questions/8028957/headers-already-sent-by-php) – mario Dec 08 '11 at 18:15
  • @all above: guys, to simplify, the code as you see it is between . As I mentioned, I don't send anything before. The same code in on the three servers, so it's not a programming issue. – Ginger Opariti Dec 08 '11 at 18:17
  • Thanks to all the contributors and to the helpful answers, here is the solution that makes, however, a large debate on the PHP forums: Place `ob_start();` at the beginning and `ob_flush();` at the end of the main script (assembler of the page, for me is the pseudo-controller). It works everywhere. HTH – Ginger Opariti Dec 08 '11 at 19:53
  • Using a crutch will never make a solution. – Your Common Sense Dec 08 '11 at 20:11
  • @Col. Shrapnel: I've marked your contribution since it is one straight to my finding if you read last phrase of your posting (therefore I wonder where you see the crutch). No need to be grumpy fellow! – Ginger Opariti Dec 09 '11 at 13:52
  • Output buffering is a distinct mechanism. And it has nothing to do with your problem. My statement was just an explanation of the behavior, not a proposed solution, as it doesn't solve anything. Your problem is inconsistent and illogical code, which is sending headers after actual output. Instead of correcting it, you are just using an irrelevant tool as a crutch. That's all. It IS a crutch - instead of making your code walk straight, you keep it stumble with a crutch. Just a metaphor, nothing personal here. – Your Common Sense Dec 09 '11 at 15:38

4 Answers4

3

Javascript is not the portable solution,
but the least portable solution.

The unknown output could be caused by some white-spaces like BOM.
Or you can take a look on headers_sent

Community
  • 1
  • 1
ajreal
  • 46,720
  • 11
  • 89
  • 119
  • I don't want to get into comments about using JavaScript, is not the scope of my post. No white spaces either. Again, the code is identical on all three servers. – Ginger Opariti Dec 08 '11 at 18:21
  • there are three answers explain what are the possibilities, what have you try so far? as your comment about the javascript is not helping to solve this problem (off-topic). you should include the php settings into your question. – ajreal Dec 08 '11 at 18:26
1

"Headers already sent" error is caused by outputting some content. Including whitespace.

Grab the outgoing response (the page that should redirect you, but didn't) and examine it's contents.

You should see only the error message "Headers already sent", nothing else. If you see something else, fix it.

Check for excessive whitespace before <?php or after closing ?> tag. The most occurring case is the later one (putting 2 linebreaks after ?>. One linebreak is ignored by the parser).

To remove this "probability for a bug", you just can remove the closing tag completely. It is not necessary.

Dalibor Filus
  • 1,140
  • 9
  • 19
  • I am flagging this answer due to it's extremely low quality. It consists of either irrelevant or simply wrong statements. So to say, raising error reporting level makes no sense in the context of the particular question. `$a[] = 'b';` statement will never raise an error. And whole "session_start is closing headers" talk is completely wrong - nowehere in the documentation can be found such a strange statement. – Your Common Sense Dec 09 '11 at 15:21
  • @Col.Shrapnel you just can't stop, do you? Ok, I will edit the answer to meet the standards. – Dalibor Filus Dec 09 '11 at 20:06
  • @Col.Shrapnel happy now? – Dalibor Filus Dec 09 '11 at 20:22
1

but I wonder what is the cause of this behavior.

This is kind of funny question.
As a matter of fact, the error message you mention has pointed out to the exact line number where the error occurs. Only you need to open that file and discover.

Most PHP users do underestimate error messages, while most of time these messages contains indispensable information and often being the only key to the problem.

It's always puzzling me - why almost noone either read or at least post the error message with their question?

As for the other servers where it works - an output buffering is on there.

Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
0

Does the third server have output buffering enabled?

If not, that would explain this - you may be outputting whitespace/html earlier in the requesy buy if buffering is enabled and you haven't output much, PHP will cope with this silently by just making sure the headers are sent before the output. With buffering disabled, it can't correct this.

It should tell you exactly which file/line caused the output to start - go there and make sure it's NOT outputting anything - whitespace outside tags, error messages, print or echo, etc...

Basic
  • 26,321
  • 24
  • 115
  • 201