(Solved) How to fix “Headers already sent” error in PHP

by

Introduction

Headers already sent error is a common issue encountered by PHP developers. This error occurs when the server sends the response to the browser before the header information is sent. This can be caused by a number of things, such as extra whitespace, incorrect line endings, or even a missing semicolon. Fortunately, this error can be easily fixed by following a few simple steps. In this article, we will discuss how to fix the “Headers already sent” error in PHP. We will cover the causes of this error, how to identify it, and the steps to take to fix it. By the end of this article, you should have a better understanding of how to troubleshoot and fix this error.

Solution

The “Headers already sent” error in PHP is caused by having any output (such as HTML or whitespace) before the header() function is called. To fix this error, you must ensure that no output is sent before the header() function is called.

This can be done by removing any whitespace or HTML before the header() function, or by using output buffering. Output buffering allows you to capture all output before it is sent to the browser, and then send it all at once. This can be done by adding the following line of code at the top of your PHP script:

ob_start();

This will start output buffering, and all output will be stored in a buffer until the ob_end_flush() function is called. Once the ob_end_flush() function is called, all output will be sent to the browser.

No output before sending headers!

Functions that send/modify HTTP headers must be invoked before any output is made.
summary ⇊
Otherwise the call fails:

Warning: Cannot modify header information – headers already sent (output started at script:line)

Some functions modifying the HTTP header are:

Output can be:

  • Unintentional:

    • Whitespace before <?php or after ?>
    • The UTF-8 Byte Order Mark specifically
    • Previous error messages or notices

  • Intentional:

    • print, echo and other functions producing output
    • Raw <html> sections prior <?php code.

Why does it happen?

To understand why headers must be sent before output it’s necessary
to look at a typical HTTP
response. PHP scripts mainly generate HTML content, but also pass a
set of HTTP/CGI headers to the webserver:

HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="https://jassweb.com/"> <img src=internal-icon-delayed> </a>

The page/output always follows the headers. PHP has to pass the
headers to the webserver first. It can only do that once.
After the double linebreak it can nevermore amend them.

When PHP receives the first output (print, echo, <html>) it will
flush all collected headers. Afterward it can send all the output
it wants. But sending further HTTP headers is impossible then.

How can you find out where the premature output occurred?

The header() warning contains all relevant information to
locate the problem cause:

Warning: Cannot modify header information – headers already sent by
(output started at /www/usr2345/htdocs/auth.php:52) in
/www/usr2345/htdocs/index.php on line 100

Here “line 100” refers to the script where the header() invocation failed.

The “output started at” note within the parenthesis is more significant.
It denominates the source of previous output. In this example, it’s auth.php
and line 52. That’s where you had to look for premature output.

Typical causes:

  1. Print, echo

    Intentional output from print and echo statements will terminate the opportunity to send HTTP headers. The application flow must be restructured to avoid that. Use functions
    and templating schemes. Ensure header() calls occur before messages
    are written out.

    Functions that produce output include

    • print, echo, printf, vprintf
    • trigger_error, ob_flush, ob_end_flush, var_dump, print_r
    • readfile, passthru, flush, imagepng, imagejpeg

    among others and user-defined functions.

  2. Raw HTML areas

    Unparsed HTML sections in a .php file are direct output as well.
    Script conditions that will trigger a header() call must be noted
    before any raw <html> blocks.

    <!DOCTYPE html>
<?php
    // Too late for headers already.

    Use a templating scheme to separate processing from output logic.

    • Place form processing code atop scripts.
    • Use temporary string variables to defer messages.
    • The actual output logic and intermixed HTML output should follow last.

  3. Whitespace before <?php for “script.php line 1” warnings

    If the warning refers to output inline 1, then it’s mostly
    leading whitespace, text or HTML before the opening <?php token.

     <?php
# There's a SINGLE space/newline before <? - Which already seals it.

    Similarly it can occur for appended scripts or script sections:

    ?>

<?php

    PHP actually eats up a single linebreak after close tags. But it won’t
    compensate multiple newlines or tabs or spaces shifted into such gaps.

  4. UTF-8 BOM

    Linebreaks and spaces alone can be a problem. But there are also “invisible”
    character sequences that can cause this. Most famously the
    UTF-8 BOM (Byte-Order-Mark)
    which isn’t displayed by most text editors. It’s the byte sequence EF BB BF, which is optional and redundant for UTF-8 encoded documents. PHP however has to treat it as raw output. It may show up as the characters  in the output (if the client interprets the document as Latin-1) or similar “garbage”.

    In particular graphical editors and Java-based IDEs are oblivious to its
    presence. They don’t visualize it (obliged by the Unicode standard).
    Most programmer and console editors however do:

    joes editor showing UTF-8 BOM placeholder, and MC editor a dot

    There it’s easy to recognize the problem early on. Other editors may identify
    its presence in a file/settings menu (Notepad++ on Windows can identify and
    remedy the problem),
    Another option to inspect the BOMs presence is resorting to an hexeditor.
    On *nix systems hexdump is usually available,
    if not a graphical variant which simplifies auditing these and other issues:

    beav hexeditor showing utf-8 bom

    An easy fix is to set the text editor to save files as “UTF-8 (no BOM)”
    or similar to such nomenclature. Often newcomers otherwise resort to creating new files and just copy&pasting the previous code back in.

    Correction utilities

    There are also automated tools to examine and rewrite text files
    (sed/awk or recode).
    For PHP specifically there’s the phptags tag tidier.
    It rewrites close and open tags into long and short forms, but also easily
    fixes leading and trailing whitespace, Unicode and UTF-x BOM issues:

    phptags  --whitespace  *.php

    It’s safe to use on a whole include or project directory.

  5. Whitespace after ?>

    If the error source is mentioned as behind the
    closing ?>
    then this is where some whitespace or the raw text got written out.
    The PHP end marker does not terminate script execution at this point. Any text/space characters after it will be written out as page content
    still.

    It’s commonly advised, in particular to newcomers, that trailing ?> PHP
    close tags should be omitted. This eschews a small portion of these cases.
    (Quite commonly include()d scripts are the culprit.)

  6. Error source mentioned as “Unknown on line 0”

    It’s typically a PHP extension or php.ini setting if no error source
    is concretized.

    • It’s occasionally the gzip stream encoding setting
      or the ob_gzhandler.
    • But it could also be any doubly loaded extension= module
      generating an implicit PHP startup/warning message.

  7. Preceding error messages

    If another PHP statement or expression causes a warning message or
    notice being printed out, that also counts as premature output.

    In this case you need to eschew the error,
    delay the statement execution, or suppress the message with e.g.
    isset() or @() –
    when either doesn’t obstruct debugging later on.

No error message

If you have error_reporting or display_errors disabled per php.ini,
then no warning will show up. But ignoring errors won’t make the problem go
away. Headers still can’t be sent after premature output.

So when header("Location: ...") redirects silently fail it’s very
advisable to probe for warnings. Reenable them with two simple commands
atop the invocation script:

error_reporting(E_ALL);
ini_set("display_errors", 1);

Or set_error_handler("var_dump"); if all else fails.

Speaking of redirect headers, you should often use an idiom like
this for final code paths:

exit(header("Location: /finished.html"));

Preferably even a utility function, which prints a user message
in case of header() failures.

Output buffering as a workaround

PHPs output buffering
is a workaround to alleviate this issue. It often works reliably, but shouldn’t
substitute for proper application structuring and separating output from control
logic. Its actual purpose is minimizing chunked transfers to the webserver.

  1. The output_buffering=
    setting nevertheless can help.
    Configure it in the php.ini
    or via .htaccess
    or even .user.ini on
    modern FPM/FastCGI setups.
    Enabling it will allow PHP to buffer output instead of passing it to the webserver instantly. PHP thus can aggregate HTTP headers.

  2. It can likewise be engaged with a call to ob_start();
    atop the invocation script. Which however is less reliable for multiple reasons:

    • Even if <?php ob_start(); ?> starts the first script, whitespace or a
      BOM might get shuffled before, rendering it ineffective.

    • It can conceal whitespace for HTML output. But as soon as the application logic attempts to send binary content (a generated image for example),
      the buffered extraneous output becomes a problem. (Necessitating ob_clean()
      as a further workaround.)

    • The buffer is limited in size, and can easily overrun when left to defaults.
      And that’s not a rare occurrence either, difficult to track down
      when it happens.

Both approaches therefore may become unreliable – in particular when switching between
development setups and/or production servers. This is why output buffering is
widely considered just a crutch / strictly a workaround.

See also the basic usage example
in the manual, and for more pros and cons:

  • What is output buffering?
  • Why use output buffering in PHP?
  • Is using output buffering considered a bad practice?
  • Use case for output buffering as the correct solution to “headers already sent”

But it worked on the other server!?

If you didn’t get the headers warning before, then the output buffering
php.ini setting
has changed. It’s likely unconfigured on the current/new server.

Checking with headers_sent()

You can always use headers_sent() to probe if
it’s still possible to… send headers. Which is useful to conditionally print
info or apply other fallback logic.

if (headers_sent()) {
    die("Redirect failed. Please click on this link: <a href=...>");
}
else{
    exit(header("Location: /user.php"));
}

Useful fallback workarounds are:

  • HTML <meta> tag

    If your application is structurally hard to fix, then an easy (but
    somewhat unprofessional) way to allow redirects is injecting a HTML
    <meta> tag. A redirect can be achieved with:

     <meta http-equiv="Location" content="http://example.com/">

    Or with a short delay:

     <meta http-equiv="Refresh" content="2; url=../target.html">

    This leads to non-valid HTML when utilized past the <head> section.
    Most browsers still accept it.

  • JavaScript redirect

    As alternative a JavaScript redirect
    can be used for page redirects:

     <script> location.replace("target.html"); </script>

    While this is often more HTML compliant than the <meta> workaround,
    it incurs a reliance on JavaScript-capable clients.

Both approaches however make acceptable fallbacks when genuine HTTP header()
calls fail. Ideally you’d always combine this with a user-friendly message and
clickable link as last resort. (Which for instance is what the http_redirect()
PECL extension does.)

Why setcookie() and session_start() are also affected

Both setcookie() and session_start() need to send a Set-Cookie: HTTP header.
The same conditions therefore apply, and similar error messages will be generated
for premature output situations.

(Of course, they’re furthermore affected by disabled cookies in the browser
or even proxy issues. The session functionality obviously also depends on free
disk space and other php.ini settings, etc.)

Further links

20

solved How to fix “Headers already sent” error in PHP

Solved: How to Fix “Headers Already Sent” Error in PHP

Have you ever encountered the dreaded “Headers already sent” error in PHP? If so, you know how frustrating it can be. Fortunately, there are a few simple steps you can take to fix this issue and get your code running smoothly again.

What is the “Headers Already Sent” Error?

The “Headers already sent” error occurs when a PHP script tries to send an HTTP header after it has already sent output to the browser. This can happen if there is whitespace or extra characters before the opening tag. It can also happen if you are using output buffering and the script tries to send an HTTP header after it has already sent output to the browser.

How to Fix the “Headers Already Sent” Error

The first step is to identify where the extra characters are coming from. This can be done by looking at the error message, which will tell you the exact line number where the problem is occurring. Once you have identified the source of the problem, you can take the following steps to fix it:

  • Remove any whitespace or extra characters before the opening
  • Remove any whitespace or extra characters after the closing ?> tag.
  • If you are using output buffering, make sure that the HTTP headers are sent before any output is sent to the browser.

Once you have taken these steps, the “Headers already sent” error should be fixed and your code should be running smoothly again.