How to fix Headers already sent error in PHP
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:
header
/header_remove
session_start
/session_regenerate_id
setcookie
/setrawcookie
Output can be:
Unintentional:
- Whitespace before
<?php
or after?>
- The UTF-8 Byte Order Mark specifically
- Previous error messages or notices
- Whitespace before
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="/"> <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:
Print, echo
Intentional output from
print
andecho
statements will terminate the opportunity to send HTTP headers. The application flow must be restructured to avoid that. Use functions
and templating schemes. Ensureheader()
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.Raw HTML areas
Unparsed HTML sections in a
.php
file are direct output as well.
Script conditions that will trigger aheader()
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.
Whitespace before
<?php
for "script.php line 1" warningsIf 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:
?>
<?phpPHP actually eats up a single linebreak after close tags. But it won't
compensate multiple newlines or tabs or spaces shifted into such gaps.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 sequenceEF 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: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 systemshexdump
is usually available,
if not a graphical variant which simplifies auditing these and other issues: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
orrecode
).
For PHP specifically there's thephptags
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.
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 commonlyinclude()d
scripts are the culprit.)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 theob_gzhandler
. - But it could also be any doubly loaded
extension=
module
generating an implicit PHP startup/warning message.
- It's occasionally the
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.
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.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. (Necessitatingob_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>
tagIf 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
- Google provides a lengthy list of similar discussions.
- And of course many specific cases have been covered on Stack Overflow as well.
- The WordPress FAQ explains How do I solve the Headers already sent warning problem? in a generic manner.
- Adobe Community: PHP development: why redirects don't work (headers already sent)
- Nucleus FAQ: What does "page headers already sent" mean?
- One of the more thorough explanations is HTTP Headers and the PHP header() Function - A tutorial by NicholasSolutions (Internet Archive link).
It covers HTTP in detail and gives a few guidelines for rewriting scripts.
PHP - cannot modify header information - headers already sent by (output started at
From php documentation:
Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP.
So move header('Location: reset.php?username='.$username);
before any other kind of output.
By the way, this question was already answered:
- How to fix "Headers already sent" error in PHP
- PHP Header redirect not working
How to fix “Headers already sent” error in PHP
This type of problem is caused when you use header after you write in your page. I assume you code might look like ::
<html>
<head>
<title> title </title>
.........
</head>
<body>
.....
<?php
header() // checking some header
?>
.....
</body>
</html>
If so, use header() before html
or any kind of echo or writing code. But this is not correct solutions. You can use ob_start
. This is the best solution. check this
PHP Error : Warning: Cannot modify header information - headers already sent by
You sent HTML before calling ob_start()
. So when PHP tries to set your session cookie, it can't, and you get the warning.
To fix it, move the PHP code for ob_start()
to the very top of the file:
<?php
ob_start();
session_start();
?>
<!DOCTYPE....
Warning: Cannot modify header information - headers already sent by ERROR
The long-term answer is that all output from your PHP scripts should be buffered in variables. This includes headers and body output. Then at the end of your scripts do any output you need.
The very quick fix for your problem will be to add
ob_start();
as the very first thing in your script, if you only need it in this one script. If you need it in all your scripts add it as the very first thing in your header.php file.
This turns on PHP's output buffering feature. In PHP when you output something (do an echo or print) it has to send the HTTP headers at that time. If you turn on output buffering you can output in the script but PHP doesn't have to send the headers until the buffer is flushed. If you turn it on and don't turn it off PHP will automatically flush everything in the buffer after the script finishes running. There really is no harm in just turning it on in almost all cases and could give you a small performance increase under some configurations.
If you have access to change your php.ini configuration file you can find and change or add the following
output_buffering = On
This will turn output buffering out without the need to call ob_start().
To find out more about output buffering check out http://php.net/manual/en/book.outcontrol.php
Warning: Cannot modify header information - headers already sent by error
Lines 45-47:
?>
<?php
That's sending a couple of newlines as output, so the headers are already dispatched. Just remove those 3 lines (it's all one big PHP block after all, no need to end PHP parsing and then start it again), as well as the similar block on lines 60-62, and it'll work.
Notice that the error message you got actually gives you a lot of information to help you find this yourself:
Warning: Cannot modify header
information - headers already sent by
(output started at
C:\xampp\htdocs\speedycms\deleteclient.php:47)
in
C:\xampp\htdocs\speedycms\deleteclient.php
on line 106
The two bolded sections tell you where the item is that sent output before the headers (line 47) and where the item is that was trying to send a header after output (line 106).
Related Topics
Get Selected Option in PHP Without Pressing Submit
How to Get Newest Data With 'Created_At' Column
How to Pass a PHP Variable Using the Url
How to Install Imagick/Imagemagick PHP Extension on Windows 7
Dompdf Not Rendering Images from the Server But Is Rendering from External Source
How to Fetch Record of Many Ids on Single Query
How to Pass Variable Between Two Web Pages With PHP Without Using Session
Laravel Eloquent Sum of Multiplied Columns
Dynamic Menu and Role Permission in Codeigniter
How to Find Out If CSV File Fields Are Tab Delimited or Comma Delimited
How to Add Auto Numbering With Each Fetching Row
How to Send Data Using Redirect With Laravel
Php Json String, Escape Double Quotes for Js Output
How to Enable the Mysqli Extension in PHP 7
PHP - Ssl Certificate Error: Unable to Get Local Issuer Certificate