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

go to bug id or search bugs for

Bug #22713 Strange HTTP headers behaviour when using output buffering and callback
Submitted: 2003-03-14 15:21 UTC Modified: 2003-07-20 10:35 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: public at asd-group dot com Assigned:
Status: No Feedback Package: Output Control
PHP Version: 4.3.2-RC OS: Windows XP
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: public at asd-group dot com
New email:
PHP Version: OS:

 

 [2003-03-14 15:21 UTC] public at asd-group dot com 
I'm using output buffering with a callback specified in ob_start. I'm also using the second parameter of value 2 (callback gets called each time output occurs in the application, rather than just once when the whole output buffer is flushed).

My callback always returns an empty string, telling PHP to ignore the output, however as soon as this happens (ie. first 'echo' or 'print' statement in application) headers_sent starts to return true.

However the HTTP headers (and terminating blank line) cant have been sent because my own calls to header() later on (eg. to set cookies) still work. 

Also, due to this, any code which expects output buffering to be on, and which checks headers_sent() before sending its own headers (after doing HTML output) will break using output buffering this way.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-15 09:46 UTC] sniper@php.net 
Did you read the 'How to report' page at all?
Did you try the latest stable snapshot from http://snaps.php.net yet? We're about to release 4.3.2 soon, 
so you really should test it.

But most important: Add a short example script which clearly shows the problem.
 [2003-03-17 13:58 UTC] public at asd-group dot com 
Hmm I did read and follow the notes, and the following sample script is easily extacted from my description. 4.3.2 made no difference.

<?php

   $Html = Array();

   // Output buffering callback - just buffers text and returns "" to PHP (telling it to ignore output)
   function PhpOutputCb ($txt)
   {
      global $Html;
      if ($txt != "")
         {$Html[] = $txt;}
      return "";
   }

   // Install output buffering callback, called on each output statement (due to second parameter)
   // ISSUE: Second parameter should be documented
   ob_start('PhpOutputCb', 2);

   $t = "<pre>Before first output statement, headers_sent() = " . (int) headers_sent() . " </pre>\n";

   echo "<html>\n".
        "<head>\n".
        "<meta http-equiv=\"Content-Type\" content=\"text/html; charset=windows-1252\">\n".
        "<meta http-equiv=\"Content-Language\" content=\"en-us\">\n".
        "<title>Bug1</title>\n".
        "</head>\n".
        "<body>\n".
        $t . "\n";

   // ISSUE: Why does headers_sent() now return true, even though headers should not have been sent (as no output actually sent)
   echo "<pre>After first output statement, headers_sent() = " .  (int)  headers_sent() . " </pre>\n";

   echo "</body>\n".
        "</html>\n";

   // QUESTION: If commented-in, this exit() call causes PhpOutputCb to be called with "" text - why ??
   //exit();

   // Turn off output buffering and physically output text which our callback buffered
   ob_end_clean();
   foreach ($Html as $key => $val)
    { echo $val; }
?>
 [2003-03-17 20:08 UTC] sniper@php.net 
Here's the proto for ob_start():

proto bool ob_start([ string|array user_function [, int chunk_size [, bool erase]]])

The 2nd parameter determines the chunk size..not how many times the callback is called.
 [2003-03-17 20:46 UTC] public at asd-group dot com 
I'm not sure how this just became a documentation problem.

Sure, the recent manuals are incomplete/wrong with respect to ob_start, and that should be corrected.

And regarding the chunk size parameter, I can tell you from actual testing and feedback from someone who knows the PHP source code (see http://www.zend.com/phorum/read.php?num=3&id=23814&loc=0&thread=23814) that it *DOES* cause the output callback to be called *ONCE* for each output statement, whether it is just one character (echo "1") or many (echo "A very,very,.....very,very long string"). 

That doesnt sound like setting a chunk size of 2 to me (assuming that means that the output buffer is flushed in chunks of 2 characters - without the correct info in the manual its hard to know).

However, in any event, if the output callback instructs PHP to ignore the output text (by returning "") then headers should not be flushed and headers_sent() should continue to return FALSE.

In a much larger application (too large to post), where I first saw this, there's an an additional curiosity. With output being captured and 'thrown away' by the output callback in this manner, the first 'echo' statement causes headers_sent() to return true, yet the code later does header() calls to set cookies, and these do not fail with a 'headers already sent' type of message (and the cookies get sent).

I hoped to reproduce this within the little code snippet above, but that does fail with the expeced message if a call to header() is made after the first echo statement.

Please could you recategorise this to a code issue.
 [2003-03-22 11:22 UTC] public at asd-group dot com 
Anyone looking at this problem - there is no workaround to this, so a fix is needed?
 [2003-04-28 12:33 UTC] wez@php.net 
Related to #21637, assuming that you are using ISAPI.
 [2003-07-13 00:06 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And update the version if it still happens with the snapshot.
 [2003-07-20 10:35 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 14:00:01 2025 UTC