PHP Doku:: Prüft, ob oder wo die Header bereits gesendet wurden - function.headers-sent.html

Verlauf / Chronik / History: (1) anzeigen

Sie sind hier:
Doku-StartseitePHP-HandbuchFunktionsreferenzSonstige DiensteNetworkNetzwerk-Funktionenheaders_sent

Ein Service von Reinhard Neidl - Webprogrammierung.





(PHP 4, PHP 5)

headers_sentPrüft, ob oder wo die Header bereits gesendet wurden


bool headers_sent ([ string &$file [, int &$line ]] )

Prüft, ob oder wo die Header bereits gesendet wurden.

Sobald der Header-Block gesendet wurde, können Sie keine weiteren Header-Zeilen mit der Funktion header() hinzufügen. Mittels dieser Funktion können Sie aber zumindest Fehlermeldungen bezüglich der HTTP-Header vermeiden. Eine andere Möglichkeit ist die Verwendung von Output Buffering.



Sind die optionalen Parameter file und line angegeben, schreibt headers_sent() den PHP-Dateinamen und die Zeilennummer, an denen die Ausgabe begann, in die Variablen file und line.


Die Zeilennummer, an der die Ausgabe begann.


headers_sent() gibt FALSE zurück, wenn noch keine HTTP-Header gesendet wurden, ansonsten TRUE.


Version Beschreibung
4.3.0 Die optionalen Parameter file und line wurden eingeführt.


Beispiel #1 Beispiel zur Verwendung von headers_sent()


// Wenn keine Header gesendet wurden, sende einen
if (!headers_sent()) {
header ('Location:');

// Ein Beispiel für den Einsatz der seit PHP 4.3.0 verfügbaren optionalen
// Parameter file und line. Beachten Sie, dass $filename und $linenum für
// einen späteren Einsatz übergeben werden.
// Weisen Sie ihnen davor keine Werte zu.
if (!headers_sent($filename$linenum)) {
header ('Location:');

// Wahrscheinlich wollen Sie hier eine Fehlermeldung auslösen
} else {

"Header bereits gesendet in $filename in Zeile $linenum\n" .
"Redirect nicht moeglich, klicken Sie daher statt dessen <a " .
"href=\"\">diesen Link</a> an\n";


Siehe auch

  • ob_start() - Ausgabepufferung aktivieren
  • trigger_error() - Erzeugt eine benutzerdefinierte Fehlermeldung/Warnung/Benachrichtigung
  • headers_list() - Gibt eine Liste der gesendeten (oder zum Senden vorbereiteten) Response Header zurück
  • header() - Sendet einen HTTP-Header in Rohform for a more detailed discussion of the matters involved.

17 BenutzerBeiträge:
- Beiträge aktualisieren...
21.10.2010 11:10
Here a function to check also if any other outout is already sent:

function output_send(){
    if (!
headers_sent() && error_get_last()==NULL ) {

8.04.2009 15:42
This is becoming annoying the amount of posts to try and describe the behaviour of headers

Headers appear first in the data sent to the user's browser

if headers have been called using the header() function but no data has been sent to the output buffer (using echo, readfile etc), then the headers are sent at the end of script execution otherwise they are sent when the buffer reaches it's limit and emptied


this means that headers_sent() will return false if nothing is sent to the output buffer because the headers are being sent at the end of the script

This is not a bug either, this is expected behaviour. Keeping headers until forced to send them out is a good idea because certain measures can be taken like prevention of meta injection etc (option in header() to replace headers that have not yet been sent)

besides, headers_sent() is good for when you try and send headers but the output buffer has already been emptied (in cases of php error handling for example). Obviously if the buffer has emtpied, sending headers won't work.
yesmarklapointe at hotmail dot com
22.10.2008 3:07
I was having trouble getting my mind around the concepts involved. Here is my dilemma and the conclusion I reached in case recounting them can help others:

I am using WAMPserver: PHP 5.2.6, and Apache 2.2.8 on Windows XP SP3. If it matters to your duplication,
I found two php.ini files in WAMPserver where output_buffering had been set to 4096. I changed them to OFF for this testing.

Here is how you can replicate what I am experiencing: With IE 7.0 go to Tools ... Display ieHTTPheaders ... and run the following script repeatedly and watch what happens:

( 'Expires: Mon, 26 Jul 1998 05:00:00 GMT' );
//echo "whatever";

Result: the final var_dump of the headers_sent() function will
always return FALSE unless any one or  more of the commented lines above it are uncommented. Uncommenting the statements allows an output to be sent to the user not just to their browser, after which the final var_dump will return TRUE. What I found confusing was that the ieHTTPheaders tool shows that the header is being sent to the user's browser even when all the output lines are commented out. So why does headers_sent() return FALSE in this case? Because you can keep sending other headers. The headers_sent function is meant to alert one to when no further headers can be sent. My testing shows it does not return true unless some other output is also sent after the header, thereby signaling that  "Headers have been sent and concluded with user output. NOW you can't send any more headers."

Someone else worked his way through this problem in a (false) bug report:
Here is the relevant part of the reply from the pro:
"When you use compression the entire page is buffered in memory, until end of the request. Consequently you can send headers at any time because no data is being actually sent to user when you print it. Until PHP actually decides to send any page output to the user you can still send additional headers which is why the headers_sent() function is returning false. It will return true, indicating that headers have been sent  only at a time when output began going to the user and you no longer can send any additional headers."

So in summary, my point is that there is a difference between headers being sent only to the browser (which can be followed by other headers) vs. headers being sent and concluded by output for the user. The function should have been given a more clear name like headers_concluded().
loaded67 at hotmail dot com
18.02.2008 7:54
very handy function!

When working with GD I made something like:

class image{

     * show
     * sends image to browser and destroy the resource if headers not sent.
     * @final
     * @static
     * @access public
     * @param resource $resource
     * @param int $type
final static public function show($resource, $type){
header('Cache-control: private');
IMAGETYPE_GIF :    header('Content-type: image/gif');
header('Content-Disposition: filename='.basename(__FILE__).'.gif');
IMAGETYPE_JPEG :     header('Content-type: image/jpeg');
header('Content-Disposition: filename='.basename(__FILE__).'.jpg');
imagejpeg($resource, NULL, 99);
IMAGETYPE_PNG :     header('Content-type: image/png');
header('Content-Disposition: filename='.basename(__FILE__).'.png');
imagepng($resource, NULL, 0NULL);

This way if you are debugging... and flush output... you will not get the endless list of headers allready send errors...

Hope it's helpfull... ;)
12.02.2008 21:33
I used $file from headers_sent() to determine if output has started rather than if headers have started to be sent; because the output hasn't started in between headers. This was to determine how long the xml serializer was taking to render output in my project.

# if debugging then...
DEBUG && register_shutdown_function( 'timer::comment' );
abstract class
timer {
# I would post the rest of the class, however it is too long.
# Use some imagination ;D
#    ...
public static function comment() {
headers_sent( $file );
        if (
$file )
'<!-- render time="' . timer::stop() . '" /-->' . LINEBREAK );

vasnake at gmail dot com
23.07.2007 0:55
In my case, when I install PHP 5.2.1 in CGI mode under Apache 2.2.3 (on windows 2003 SP2),
function sent_headers() always return false. flash(), ob_end_flash(), so on... no matter.
I suppose, Apache buffering all PHP output until exit()
collectours at free dot fr
18.06.2007 11:32
In response to K.Tomono and alexrussell101 at gmail dot com :

headers_sent() will return false, even if you sent something to the ouptut using print() or header() , if output_buffering is different from Off in you php.ini, and the length of what you sent does not exceed the size of output_buffering.

To test it, try this code with  these values in php.ini
1) output_buffering=32
2) output buffering = 4096

echo "Yo<br />";
"Sent:",headers_sent(),"<br />";
"enough text to feed the buffer until it overflows ;-)<br />";
"Sent:",headers_sent(),"<br />";

then put
3) output buffering = Off
and try this code
echo "Yo<br />";
"Sent:",headers_sent(),"<br />";
which will this time unconditionnally say that headers were sent.

This is noticed in php.ini comment :
"Output buffering allows you to send header lines (including cookies) even after you send body content, in the price of slowing PHP's output layer a bit."

Note : This is completly independant of implicit_flush tuning.
kamermans at teratechnologies dot net
21.08.2006 22:24
If you are using output buffering and you use the flush() command ANYWHERE headers_sent() will return true - even if the buffer is seemingly empty.
Jakob B.
7.01.2006 12:03
function redirect($filename) {
    if (!
header('Location: '.$filename);
    else {
'<script type="text/javascript">';
'<meta http-equiv="refresh" content="0;url='.$filename.'" />';
trevize (shtrudel)
30.11.2005 15:43
Note that in IIS (or at least the version that comes with W2K server), the server seems to do some buffering, so even if you output someting or cause a warning, the value of headers_sent() may be false because the headers haven't been sent yet.

So it's not a safe way to know if warnings have been encountered in your script.
php [at] barryhunter [.] co [.] uk
9.09.2005 12:42
In responce to: Terry 11-Feb-2005 03:58

if PHP is run as a Module, then it will behave as you describe

However if PHP is run as a CGI then it will be behave like Perl, (which uses CGI unless its mod_perl), as this is a CGI behaviour.

alexrussell101 at gmail dot com
2.09.2005 0:31
To K.Tomono:

Headers are not sent as soon as you call the header() function. They are only sent as soon as some body content (i.e. HTML via echo or escaping from PHP parsing mode) is reached (or, like you did, you send a flush.) Thus after calling header a few times at the beginning they are still unsent and when you call headers_sent() it knows they haven't been sent and reports so. Only when the script ends or you output from content do all the headers so far send.
I think you misunderstood the way they are done and hopefully this should clear a few things up for you.
mark at dreamjunky dot com
28.06.2005 18:56
In case this comes up with anyone else, you might trigger headers to be sent if you have a PHP file with extra space after the closing ?>.  In particular, if you include that file at the top of your main script, it will cause headers to send, followed by the space after the ?> in your included script.  In short, make sure you don't have any space trailing your final ?>.
22.04.2005 7:24
("Cache-Control: private, must-revalidate, max-age=3600, post-check=3600, pre-check=3600");
////header("Last-Modified: " . gmdate("D, d M Y H:i:s",getlastmod())." GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
flush(); // <= (*1)
if (!
headers_sent()) {
header('Content-Type:text/html; charset='._CHARSET);
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
//header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
header('Cache-Control: private, no-cache');
header('Pragma: no-cache');

headers_sent() does not evaluate it as true, unless the flush()(*1) has been done.

It seems that it does not mean header was sent unless a header output is taken
out to the exterior of PHP.

Apache 2.0.53 (prefork)
PHP 5.0.3 (server module)
... And XOOPS

I had seldom paid attention to flush() on PHP which is not C.
However, it might have been a required thing.

"http ://myhost.mydomain/xoops/modules/test.php?i=1" | less
  % Total    % Received % Xferd  Average Speed          Time             Curr.
                                 Dload  Upload Total    Current  Left    Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:00 --:--:--     0

HTTP/1.1 200 OK
Date: Fri, 22 Apr 2005 05:00:11 GMT
Server: Apache
X-Powered-By: PHP/5.0.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, must-revalidate, max-age=3600, post-check=3600, pre-check=3600
Pragma: no-cache
Last-Modified: Fri, 22 Apr 2005 05:00:11 GMT
Transfer-Encoding: chunked
Content-Type: text/html
(*)"http :" is "http:" in fact.
11.02.2005 4:58
For programmers used to Perl, note that sending a relative 'Location:' header sends a redirect to the browser in PHP, unlike Perl which will attempt to call relative URLs using an internal subrequest and return that page to the browser without redirecting.  If you want to do the same trick in PHP, use include() or virtual().
php at fufachew dot REMOVEME dot com
28.02.2004 20:26
RE: antti at haapakangas dot net's post

I've changed the code so $_SERVER['SERVER_NAME'] is used if $_SERVER['HTTP_HOST'] is not set.  $_SERVER['SERVER_NAME'] doesn't meet my needs, but I suppose it's good to fall back on it.  I've also fixed a problem in the meta refresh line - it was missing the "url=" part of the content attribute.

function server_url()
$proto = "http" .
$_SERVER['HTTPS']) && $_SERVER['HTTPS'] == "on") ? "s" : "") . "://";
$server = isset($_SERVER['HTTP_HOST']) ?
$proto . $server;
$url = server_url() . dirname($_SERVER['PHP_SELF']) . "/" . $relative_url;
    if (!
header("Location: $url");
"<meta http-equiv=\"refresh\" content=\"0;url=$url\">\r\n";
antti at haapakangas dot net
28.01.2004 21:39
Re: php at fufachew dot com

That's a nice example how to implement Location header in a correct way (using absoluteURI). 95% of the scripts I have seen just use relativeURI which is wrong. Some browsers, for example lynx, actually notify user about incomplete Location headers. However it might be safer to use $_SERVER['SERVER_NAME'] instead of $_SERVER['HTTP_HOST']. Host header is a HTTP/1.1 feature and you can not count on that if you want to be interoperable with HTTP/1.0 implementations.

PHP Powered Diese Seite bei
The PHP manual text and comments are covered by the Creative Commons Attribution 3.0 License © the PHP Documentation Group - Impressum - mail("TO:Reinhard Neidl",...)