Session_start output error

liquorvicar

I'm getting intermittent errors like this:

Cannot modify header information - headers already sent by (output started at /path/to/script.php:2)

Contents of said script are:

<?
session_start();
...

This is nothing before session_start() apart from the opening PHP tag. No white-space, no includes, nothing. This is only happening in a tiny minority of cases and seems to be triggered by the same remote IP each time. From the PHP docs, it says session_start() always returns true and doesn't indicate any possible errors. My only thoughts is that the offending IP is sending a faked session ID to my script with some chars that are not allowed in a PHP session ID, although there are no errors to support this. Any other ideas? Any ways to stop this happening?

MarkR

You must be outputting something before session_start. This may be whitespace that you can't see. Your editor may be adding a unicode byte order mark to the beginning of the file- this also counts.

Use a hex editor to inspect the file to ensure that there is absolutely nothing before <?php

PS: Use long <?php tags not <?

Mark

liquorvicar

If there were whitespace before the session_start(), wouldn't that throw an error every time the page was accessed? This page is hit hundreds (possibly thousands) of times a day but it's only hits from one or two IPs that's causing the error.

MarkR wrote:
PS: Use long <?php tags not <?

I know, I do now on all new scripts but this is an old legacy script. Am trying to tidy this up bit by bit.

MarkR

Is there an auto-prepend file set?

It seems feasible that some other error which happens earlier is causing some stuff to be output (an error message).

Can you look at your PHP error log to see the problem?

Have you considered installing traffic monitoring on the server for a day or two to capture the entire request which caused the problem? (This is an extreme step and may reduce server performance)

Mark

liquorvicar

There's no auto-prepend file.

My guess was that it was an error message as you suggest. There's nothing else in my error logs that relates this time, although in the past I have seen a related error to do with invalid characters in the session ID.

Really wouldn't want to go down the traffic-monitoring route as the site is currently serving over 80,000 hits a day.

MarkR

80k hits per day isn't that many. Who cares if your log file is a few 100 megs, you can still handle it. I've dealt with packet logs that big before.

My feeling is that there is an error / notice which is happening before the beginning of the script, possibly due to (as you suggest) bad cookies. Try increasing the error level in php.ini to E_ALL and ensuring that your logs have timestamps (mine do).

Then once you have a timestamp for the error, you can correlate it with the packet log to identify the exact cause.

Of course, display_errors should normally be off in a production environment, as you don't want end-users seeing any PHP errors (it is normally sensible to have a PHP error handler show them a custom error page, but you can't set an error handler before the script starts).

Mark

liquorvicar

Thanks for the feedback MarkR.

What sort of traffic monitoring would you suggest? tcpdump? (We're on RedHat Linux). Is it possible to restrict this per remote IP/IP-range?

I had E_ALL & ~E_NOTICE so I've changed that as it may have been a notice as you point out. I also did have a custom error handler but this wouldn't have picked up any session_start errors as they would have come before the custom error handler was set.

MarkR

liquorvicar wrote:
What sort of traffic monitoring would you suggest? tcpdump? (We're on RedHat Linux). Is it possible to restrict this per remote IP/IP-range?

Yes and yes respectively. TCPdump can accept many types of filter. You can then transfer the dump file (you might want to compress it) before loading it on your desktop with something like Wireshark, which can then apply further filters.

I had E_ALL & ~E_NOTICE so I've changed that as it may have been a notice as you point out.

Don't ignore notices, they are VERY important, especially in your development environment. Many E_NOTICEs indicate a programming error.

A well written application should generate no E_NOTICEs during normal operation. Our error handler aborts the page if one is detected.

I also did have a custom error handler but this wouldn't have picked up any session_start errors as they would have come before the custom error handler was set.

True. This is annoying.

Mark

liquorvicar

Thanks, will get my head down and read up on tcpdump.

My custom error handler picks up on E_NOTICEs already - you're right that many of them indicate bad programming practices/programming errors. It's just it won't have picked up any E_NOTICEs before it gets set. Grrr.