Suppress 'Headers Already Sent' in Config?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hi folks.

I'm trying to set up on a local PC a development version of a live website
(that I didn't write). I'm quite green with respect to PHP/Apache config,
and I'm using XAMPP on the local PC.

The local version of the website produces 'Cannot send session cache
limiter - headers already sent' warnings (and I know enough PHP to know why
it does that), whereas the live website doesn't generate those messages.

I don't think it's just a matter of error reporting, because a
widely-included PHP script on the site sets 'error_reporting(E_ALL)'.

I'm kind of assuming that maybe the configuration of either PHP or Apache
(or both) on the live server somehow prevents those messages, but it may not
be just the suppression of messages that's happening on the live site -- as
the website liberally uses (and relies upon) session_start()s that
presumably work fine on the live server.

So... is there a way, for example of configuring PHP (or Apache) to defer
sending headers or something that allows the live server to function whereas
the development server encounters issues?

Sorry for the rambling question, and thanks in advance for any hints!


Re: Suppress 'Headers Already Sent' in Config?

El 20/01/2010 10:13, Andrew C. escribió:
Quoted text here. Click to load it

The live server is probably using a feature that causes output buffering
so you have this:

header('Foo: TRUE');
echo 'Hello World!';
header('Bar: FALSE');

Sending the Bar header triggers no error beause the 'Hello World!'
string has not actually been sent to the browser: it's been queued at
the server to be delivered later.

The usual suspects are output_buffering and output_handler.

Use phpinfo() on both systems to compare settings.

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Re: Suppress 'Headers Already Sent' in Config?

Quoted text here. Click to load it

Thanks for the responses!

The difference between the live server and my XAMPP set up at home is indeed
the output_buffering setting: the live one is 4096, whereas mine at home was
(rightfully) 'Off'! :-)

For the time being, I've set mine to the same value and that's stopped the
warning messages, however, I agree with your point, Jerry, that this isn't
The Way.

... But, I was called up by someone in a panic less than 24 hours ago to fix
some urgent issues with their website (and, no, headers having been sent
wasn't one of them!) and I'm trying to fix the ultra-urgent ones on their
*live* website (at their request because of lack of alternative) with one
hand while I try to set up some kind of development version with the other
hand! :-)

And the hard-coded absolute page URLs aren't helping... ;-)

Thanks again! :-)


Re: Suppress 'Headers Already Sent' in Config?

Quoted text here. Click to load it

This is probably happening for one of two reasons. Either the live
host has error reporting turned off (a sensible precaution for a live
site as the PHP errors can give away clues to potential hackers, and
look unprofessional to normal users), or the host has output buffering
enabled.  Output buffering queues up all script output to a buffer
instead of sending it directly to the browser, meaning that the
headers can be sent regardless of when they're generated in the

Unfortunately PHP's error control is not fine grained enough to turn
error reporting off for just one class of errors (namely errors that
occur because headers have already been sent).  You can prepend the @
error suppression operator to function calls that can cause the error
you're already aware of, but this is strongly discouraged for several
reasons.  You could enable output buffering on your test box, as this
would have the effect of headers always being sent successfully.

However, supposing you run into some headers-related problem later on
in development or maintenance?  You might not be aware of it because
of the output buffering.  When someone then tries running the script
on a server that has output buffering disabled the result would be
that the script could fail.  Generally it is best to write scripts
under the assumption that buffering is disabled if possible.

As a general rule, you want your development box to emit as much data
about script problems as possible, so I would personally just live
with the issue, or attempt to rewrite your script to avoid the error
being triggered.  If you don't want all this stuff cluttering your
browser window, then there is of course setting PHP up to log errors
to a file instead of to the browser.  Or course you'd have to be
diligent about checking the log, but it would mean your browser
wouldn't be cluttered with errors while still capturing all the error
data that PHP emits.

Re: Suppress 'Headers Already Sent' in Config?

Andrew C. wrote:
Quoted text here. Click to load it

As others have said, the live server is probably either buffering the
output or disabling the error reporting.

However, you have a bigger problem - you need to fix these problems.  If
though you don't think these might be causing you problems now, it's
only a matter of time.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Suppress 'Headers Already Sent' in Config?

On Wed, 20 Jan 2010 09:13:15 -0000, Andrew C. wrote:

Quoted text here. Click to load it

Or, since these are/should be all text files, there's LOTS of ways
to fould up text files that will trip this invisibly. Did one of the
INCLUDEd files end up getting an extra space, carriage return or
linefeed at the end of it outside the trailing ?> ? That can cause thise
problem. Were the files in a strict UTF-8 encoding and now they're on
your machine and not, but still have the Byte Order Mark on the front
of them? You won't see that in most text editors, but it's enough to
trigger this kind of error as well.

I picked up a Magic 8-Ball the other day and it said 'Outlook not so
good.' I said 'Sure, but Microsoft still ships it.'
              -- Anonymous

Site Timeline