php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #77758 Warning: headers already sent should identify what triggered the send
Submitted: 2019-03-17 22:03 UTC Modified: 2019-03-18 23:17 UTC
Votes:1
Avg. Score:2.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: webmaster at jamescobban dot net Assigned:
Status: Open Package: Apache2 related
PHP Version: 7.2.16 OS: linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: webmaster at jamescobban dot net
New email:
PHP Version: OS:

 

 [2019-03-17 22:03 UTC] webmaster at jamescobban dot net 
Description:
------------
The message Warning: Cannot modify header information - headers already sent is one of the big time-wasters of our profession.  All of the documentation on this message including hundreds of web-pages and forum discussions end up as just a long list of things that the program MIGHT have done that would cause this message to appear.  There is no documentation of exactly how a programmer should go about identifying exactly what the, usually trivial, mistake was that triggered the early send of the headers.  The message should include information that directly points at the program action that caused PHP to send the headers.

Test script:
---------------
print '';  // empty string
header("Content-Type: application/json");

Expected result:
----------------
Warning: Cannot modify header information - headers already sent because of backtrace to line 1.

Actual result:
--------------
Warning: Cannot modify header information - headers already sent at line 2.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-03-17 22:08 UTC] spam2 at rhsoft dot net 
> print '';  // empty string
> header("Content-Type: application/json");

just don't echo / print anything ebfore headers, it's that easy

> headers already sent is one of the big time-wasters

just don't output anything when you intend send headers after, easy

> All of the documentation on this message including 
> hundreds of web-pages and forum discussions

just start your application with ob_start() and the problem is forever, easy
 [2019-03-18 23:17 UTC] webmaster at jamescobban dot net 
spam2 at rhsoft dot net has pointed out that the problems resulting from accidentally sending text can be avoided either by "just don't echo / print anything ebfore headers" or by wrapping everything in ob_start/ob_clean.  But neither of these help the programmer to FIX the problem, they just hide it.  The problem is that there is no clean easy way to FIND the errant output in any real-life web-site, because there can be MILLIONS of lines of code in a modern web-site, and that code is the work of multiple team members any one of which can make the small mistake.  On the web-site which triggered this suggestion the output came out of a diagnostic routine that was four nested includes deep.  Because PHP does not tell the programmer WHERE the errant print/echo statement is this required slapping hundreds of "if (headers_sent()) print "<p>" . __FILE__ . ' ' __LINE__;" statements throughout the code and then gradually narrowing in to find the offending print.  This is a brute force debugging method which is inappropriate in 2019.  Computers exist to serve humans, not the other way around.
 [2021-12-29 00:32 UTC] tdneren at gmail dot com 
[NB: I am not angry at no-one, so please use this/my steam-off in a constructive way]

When coders have to rely on stackoverflow-remedies like this; https://stackoverflow.com/questions/8028957/how-to-fix-headers-already-sent-error-in-php, in order to fix the problem, the overall problem is a tragic one.
No coder should have to go through this kind of problem. Here is how I basically made the workaround;

Not-working/prior to own fix:
<!DOCTYPE html><html>
<head><title>A title 2021</title></head>
<body>
<h2>Interact with this</h2><br><br><?php
header('Location: https://www.mysite.dk');?></body></html>

Working:
<?php
header('Location: https://www.mysite.dk');?><!DOCTYPE html><html>
<head><title>A title 2021</title></head>
<body>
<h2>Interact with this</h2><br><br></body></html>

As one can see the lines are almost nonexisting in numbers (are very few), but somehow this has wasted my time immensely, and made deep misunderstandings between me and my webhotel provider. Here is why;
When I found the problem, the problem only existed on one of my domains. Meaning that the problem - both - seems superfragile (the first code structure above works randomly on some domains, and not others), as well as tricking me into believing that the problem was related to domain setups (DNS etc). As having coded in JS and using Chrome debugging in console for months, I hadn't gotten used to using the error.log textfile, for debugging in PHP. Fortunately my webhotel provider guided me in that direction, and I finally found the stackoverflow-source ... "headers" + "whitespace"??? Seriously! No one should waste time on this again. This was the second time I fell into this pit, and neither me or others should do that -  if a json-file or .ASP-file has whitespace, the compiler does-and-should ignore them. Hopefully this will be the case for .PHP-files in the future as well (at least make it so, that it fails on 'every single php-file and domain', so I/others won't get mega-confused and tear the head off webhotel-providers [again]). //br regards and I am not angry at no-one, so please use my steam-off in a constructive way, Thomas D. from Denmark
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Dec 21 05:00:01 2025 UTC