No output before sending headers!<\/h2>\n
Functions that send\/modify HTTP headers must be invoked before any output is made<\/strong><\/em>. Warning: Cannot modify header information – headers already sent (output started at script:line<\/i>)<\/p>\n<\/blockquote>\n Some functions modifying the HTTP header are:<\/p>\n Output can be:<\/p>\n Unintentional:<\/em><\/p>\n Intentional:<\/em><\/p>\n To understand why headers must be sent before output it’s necessary The page\/output always follows<\/em> the headers. PHP has to pass the When PHP receives the first output ( The Warning: Cannot modify header information – headers already sent by Here “line 100” refers to the script where the The “output started at<\/em>” note within the parenthesis is more significant. Typical causes:<\/em><\/p>\n Intentional output from Functions that produce output include<\/p>\n among others and user-defined functions.<\/p>\n<\/li>\n Unparsed HTML sections in a Use a templating scheme to separate processing from output logic.<\/p>\n If the warning refers to output inline Similarly it can occur for appended scripts or script sections:<\/p>\n PHP actually eats up a single<\/em> linebreak after close tags. But it won’t Linebreaks and spaces alone can be a problem. But there are also “invisible” In particular graphical editors and Java-based IDEs are oblivious to its There it’s easy to recognize the problem early on. Other editors may identify An easy fix is to set the text editor to save files as “UTF-8 (no BOM)” There are also automated tools to examine and rewrite text files It’s safe to use on a whole include or project directory.<\/p>\n<\/li>\n If the error source is mentioned as behind the It’s commonly advised, in particular to newcomers, that trailing It’s typically a PHP extension or php.ini setting if no error source If another PHP statement or expression causes a warning message or In this case you need to eschew the error, If you have So when Or Speaking of redirect headers, you should often use an idiom like Preferably even a utility function, which prints a user message PHPs output buffering<\/a> The It can likewise be engaged with a call to Even if 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 buffer is limited in size, and can easily overrun when left to defaults. Both approaches therefore may become unreliable – in particular when switching between See also the basic usage example<\/a> If you didn’t get the headers warning before, then the output buffering You can always use Useful fallback workarounds are:<\/p>\n If your application is structurally hard to fix, then an easy (but Or with a short delay:<\/p>\n This leads to non-valid HTML when utilized past the As alternative a JavaScript redirect While this is often more HTML compliant than the Both approaches however make acceptable fallbacks when genuine HTTP header() Both (Of course, they’re furthermore affected by disabled cookies in the browser 20<\/span> <\/p><\/div>\n<\/div>\n
\nsummary \u21ca<\/strong><\/kbd>
\nOtherwise the call fails:<\/p>\n\n
\n
header<\/code><\/a> \/ header_remove<\/code><\/a><\/li>\nsession_start<\/code><\/a> \/ session_regenerate_id<\/code><\/a><\/li>\nsetcookie<\/code><\/a> \/ setrawcookie<\/code><\/a><\/li>\n<\/ul>\n\n
\n
<?php<\/code> or after ?><\/code><\/li>\n\n
\n
print<\/code>, echo<\/code> and other functions producing output<\/li>\n<html><\/code> sections prior <?php<\/code> code.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nWhy does it happen?<\/h2>\n
\nto look at a typical HTTP<\/a>
\nresponse. PHP scripts mainly generate HTML content, but also pass a
\nset of HTTP\/CGI headers to the webserver:<\/p>\nHTTP\/1.1 200 OK\nPowered-By: PHP\/5.3.7\nVary: Accept-Encoding\nContent-Type: text\/html; charset=utf-8\n\n<html><head><title>PHP page output page<\/title><\/head>\n<body><h1>Content<\/h1> <p>Some more output follows...<\/p>\nand <a href=\"\/\"> <img src=internal-icon-delayed> <\/a>\n<\/code><\/pre>\n
\nheaders to the webserver first. It can only do that once.
\nAfter the double linebreak it can nevermore amend them.<\/p>\nprint<\/code>, echo<\/code>, <html><\/code>) it will
\nflush<\/em> all collected headers. Afterward it can send all the output
\nit wants. But sending further HTTP headers is impossible then.<\/p>\nHow can you find out where the premature output occurred?<\/h2>\n
header()<\/code> warning contains all relevant information to
\nlocate the problem cause:<\/p>\n\n
\n(output started at<\/strong><\/em> \/www\/usr2345\/htdocs\/auth.php:52<\/b>) in
\n\/www\/usr2345\/htdocs\/index.php on line 100<\/p>\n<\/blockquote>\nheader()<\/code> invocation<\/em> failed.<\/p>\n
\nIt denominates the source of previous output. In this example, it’s auth.php<\/code>
\nand line 52<\/code><\/strong>. That’s where you had to look for premature output.<\/p>\n\n
Print, echo<\/h3>\n
print<\/code> and echo<\/code> statements will terminate the opportunity to send HTTP headers. The application flow must be restructured to avoid that. Use functions<\/a>
\nand templating schemes. Ensure header()<\/code> calls occur before<\/em> messages
\nare written out.<\/p>\n\n
print<\/code>, echo<\/code>, printf<\/code>, vprintf<\/code><\/li>\ntrigger_error<\/code>, ob_flush<\/code>, ob_end_flush<\/code>, var_dump<\/code>, print_r<\/code><\/li>\nreadfile<\/code>, passthru<\/code>, flush<\/code>, imagepng<\/code>, imagejpeg<\/code><\/li>\n<\/ul>\nRaw HTML areas<\/h3>\n
.php<\/code> file are direct output as well.
\nScript conditions that will trigger a header()<\/code> call must be noted
\nbefore any<\/em> raw <html><\/code> blocks.<\/p>\n<!DOCTYPE html>\n<?php\n \/\/ Too late for headers already.\n<\/code><\/pre>\n\n
Whitespace before
<?php<\/code> for “script.php line 1<\/strong>” warnings<\/h3>\n1<\/code><\/strong>, then it’s mostly
\nleading whitespace<\/strong>, text or HTML before the opening <?php<\/code> token.<\/p>\n <?php\n# There's a SINGLE space\/newline before <? - Which already seals it.\n<\/code><\/pre>\n?>\n\n<?php\n<\/code><\/pre>\n
\ncompensate multiple newlines or tabs or spaces shifted into such gaps.<\/p>\n<\/li>\nUTF-8 BOM<\/h3>\n
\ncharacter sequences that can cause this. Most famously the
\nUTF-8 BOM<\/strong> (Byte-Order-Mark)<\/a>
\nwhich isn’t displayed by most text editors. It’s the byte sequence EF BB BF<\/code>, 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 \u00ef\u00bb\u00bf<\/code> in the output (if the client interprets the document as Latin-1) or similar “garbage”.<\/p>\n
\npresence. They don’t visualize it (obliged by the Unicode standard).
\nMost programmer and console editors however do:<\/p>\n![\"joes](\"https:\/\/jassweb.com\/solved\/wp-content\/uploads\/2022\/08\/Solved-How-to-fix-Headers-already-sent-error-in-PHP.png\")
<\/p>\n
\nits presence in a file\/settings menu (Notepad++ on Windows can identify and
\nremedy the problem),
\nAnother option to inspect the BOMs presence is resorting to an hexeditor<\/strong>.
\nOn *nix systems hexdump<\/code><\/a> is usually available,
\nif not a graphical variant which simplifies auditing these and other issues:<\/p>\n![\"beav](\"https:\/\/jassweb.com\/solved\/wp-content\/uploads\/2022\/08\/1661011434_74_Solved-How-to-fix-Headers-already-sent-error-in-PHP.png\")
<\/p>\n
\nor similar to such nomenclature. Often newcomers otherwise resort to creating new files and just copy&pasting the previous code back in.<\/p>\nCorrection utilities
![](\"https:\/\/jassweb.com\/solved\/wp-content\/uploads\/2022\/08\/Solved-How-to-fix-Headers-already-sent-error-in-PHP.gif\")
<\/h3>\n
\n(sed<\/code>\/awk<\/code> or recode<\/code>).
\nFor PHP specifically there’s the phptags<\/code> tag tidier<\/a>.
\nIt rewrites close and open tags into long and short forms, but also easily
\nfixes leading and trailing whitespace, Unicode and UTF-x BOM issues:<\/p>\nphptags --whitespace *.php\n<\/code><\/pre>\nWhitespace after
?><\/code><\/h3>\n
\nclosing ?><\/code>
\nthen this is where some whitespace or the raw text got written out.
\nThe PHP end marker does not terminate script execution at this point. Any text\/space characters after it will be written out as page content
\nstill.<\/p>\n?><\/code> PHP
\nclose tags should be omitted. This eschews<\/em> a small portion of these cases.
\n(Quite commonly include()d<\/code> scripts are the culprit.)<\/p>\n<\/li>\nError source mentioned as “Unknown on line 0”<\/h3>\n
\nis concretized.<\/p>\n\n
gzip<\/code> stream encoding setting
\nor the ob_gzhandler<\/code>.<\/li>\nextension=<\/code> module
\ngenerating an implicit PHP startup\/warning message.<\/p>\n<\/li>\n<\/ul>\n<\/li>\nPreceding error messages<\/h3>\n
\nnotice being printed out, that also counts as premature output.<\/p>\n
\ndelay the statement execution, or suppress the message with e.g.
\nisset()<\/code><\/a> or @()<\/code><\/a> –
\nwhen either doesn’t obstruct debugging later on.<\/p>\n<\/li>\n<\/ol>\nNo error message<\/h2>\n
error_reporting<\/code> or display_errors<\/code> disabled per php.ini<\/code>,
\nthen no warning will show up. But ignoring errors won’t make the problem go
\naway. Headers still can’t be sent after premature output.<\/p>\nheader(\"Location: ...\")<\/code> redirects silently fail it’s very
\nadvisable to probe for warnings. Reenable them with two simple commands
\natop the invocation script:<\/p>\nerror_reporting(E_ALL);\nini_set(\"display_errors\", 1);\n<\/code><\/pre>\nset_error_handler(\"var_dump\");<\/code> if all else fails.<\/p>\n
\nthis for final code paths:<\/p>\nexit(header(\"Location: \/finished.html\"));\n<\/code><\/pre>\n
\nin case of header()<\/code> failures.<\/p>\nOutput buffering as a workaround<\/h2>\n
\nis a workaround to alleviate this issue. It often works reliably, but shouldn’t
\nsubstitute for proper application structuring and separating output from control
\nlogic. Its actual purpose is minimizing chunked transfers to the webserver.<\/p>\n\n
output_buffering=<\/code><\/a>
\nsetting nevertheless can help.
\nConfigure it in the php.ini<\/a>
\nor via .htaccess<\/a>
\nor even .user.ini<\/a> on
\nmodern FPM\/FastCGI setups.
\nEnabling it will allow PHP to buffer output instead of passing it to the webserver instantly. PHP thus can aggregate HTTP headers.<\/p>\n<\/li>\nob_start();<\/code><\/a>
\natop the invocation script. Which however is less reliable for multiple reasons:<\/p>\n\n
<?php ob_start(); ?><\/code> starts the first script, whitespace or a
\nBOM might get shuffled before, rendering it ineffective.<\/p>\n<\/li>\n
\nthe buffered extraneous output becomes a problem. (Necessitating ob_clean()<\/code>
\nas a further workaround.)<\/p>\n<\/li>\n
\nAnd that’s not a rare occurrence either, difficult to track down
\nwhen it happens.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
\ndevelopment setups and\/or production servers. This is why output buffering is
\nwidely considered just a crutch \/ strictly a workaround.<\/p>\n
\nin the manual, and for more pros and cons:<\/p>\n\n
But it worked on the other server!?<\/h3>\n
\nphp.ini setting<\/a>
\nhas changed. It’s likely unconfigured on the current\/new server.<\/p>\nChecking with
headers_sent()<\/code><\/h2>\nheaders_sent()<\/code><\/a> to probe if
\nit’s still possible to… send headers. Which is useful to conditionally print
\ninfo or apply other fallback logic.<\/p>\nif (headers_sent()) {\n die(\"Redirect failed. Please click on this link: <a href=...>\");\n}\nelse{\n exit(header(\"Location: \/user.php\"));\n}\n<\/code><\/pre>\n\n
HTML
<meta><\/code> tag<\/h3>\n
\nsomewhat unprofessional) way to allow redirects is injecting a HTML
\n<meta><\/code> tag. A redirect can be achieved with:<\/p>\n <meta http-equiv=\"Location\" content=\"http:\/\/example.com\/\">\n<\/code><\/pre>\n <meta http-equiv=\"Refresh\" content=\"2; url=..\/target.html\">\n<\/code><\/pre>\n<head><\/code> section.
\nMost browsers still accept it.<\/p>\n<\/li>\nJavaScript redirect<\/h3>\n
\ncan be used for page redirects:<\/p>\n <script> location.replace(\"target.html\"); <\/script>\n<\/code><\/pre>\n<meta><\/code> workaround,
\nit incurs a reliance on JavaScript-capable clients.<\/p>\n<\/li>\n<\/ul>\n
\ncalls fail. Ideally you’d always combine this with a user-friendly message and
\nclickable link as last resort. (Which for instance is what the http_redirect()<\/a>
\nPECL extension does.)<\/p>\nWhy
setcookie()<\/code> and session_start()<\/code> are also affected<\/h2>\nsetcookie()<\/code> and session_start()<\/code> need to send a Set-Cookie:<\/code> HTTP header.
\nThe same conditions therefore apply, and similar error messages will be generated
\nfor premature output situations.<\/p>\n
\nor even proxy issues. The session functionality obviously also depends on free
\ndisk space and other php.ini settings, etc.)<\/p>\nFurther links<\/h2>\n
\n
\nIt covers HTTP in detail and gives a few guidelines for rewriting scripts.<\/li>\n<\/ul>\n<\/div>\n