php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16676 ob_implicit_flush not turning off ob
Submitted: 2002-04-18 02:19 UTC Modified: 2003-01-11 18:46 UTC
Votes:23
Avg. Score:4.1 ± 1.1
Reproduced:16 of 17 (94.1%)
Same Version:6 (37.5%)
Same OS:5 (31.2%)
From: norny at yahoo dot com Assigned:
Status: Wont fix Package: Output Control
PHP Version: 4.2.0 OS: Slackware 8.0
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-04-18 02:19 UTC] norny at yahoo dot com
I have a php shell script that outputs ~100 char lines using echo. I'm trying to work around the default php.ini configuration of a 4k automatic buffer and flush the lines to the console for debugging.

Calling ob_flush() after each echo, echos the lines immediately, putting ob_end_flush() at the beginning of the script turns off ob so I get immediate output, but ob_implicit_flush() and ob_implicit_flush(1) don't seem to automatically flush after each echo. I have to wait till the end of the script execution to see the output when I try ob_implicit_flush. Using ob_end_flush() is my workaround for now.

Same difference whether I use echo or print. This is for RC4.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-18 02:57 UTC] yohgaki@php.net
I guess you are enabling zlib.output_compression.
If you are not, please change Status to "Open".
Thank you.
 [2002-04-18 03:43 UTC] norny at yahoo dot com
I can't change the status to 'Open', but I can say zlib.output_compression is off.
 [2002-04-18 03:50 UTC] norny at yahoo dot com
I tried leaving output_buffering = 4096 in php.ini and turning on implicit_flush in php.ini, and it's still not flushing my echo lines till the end of script execution, so neither the function or the ini config are working for me. If I make output_buffering = 0, it flushes correctly as expected, but as I understand it, the whole point of ob_implicit_flush() in runtime is to override the default ini config which is what I want to do.
 [2002-04-18 06:12 UTC] yohgaki@php.net
Don't worray, it's known issue.
I can make it flush when all output buffers registered may be flushed, otherwise it just does not work.

Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work.

If you need to flush, do not use output buffers at all.

Note: Older PHP is just deleted the last output buffer registered with ob_implicit_flush. This is wrong behavior.


 [2002-04-18 11:34 UTC] norny at yahoo dot com
> If you need to flush, do not use output buffers at all.

That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob.

> Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work.

I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on.
 [2002-09-26 16:47 UTC] iliaa@php.net
Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php

Thank you for your interest in PHP.

if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. 
 [2002-12-24 16:25 UTC] norny at yahoo dot com
iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script.

As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed".

I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT.

By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob.

Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out.
 [2002-12-24 21:39 UTC] edink@php.net
You can solve your problem by putting @ob_end_flush(); on top of your command line scripts.
 [2002-12-27 08:16 UTC] yohgaki@php.net
It is easy to make it actually flush output. Difficult part is make it work always.

Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed.

Fix is simple, but you have to live with that.
If you are interested, search php-dev archive.

BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;)




 [2002-12-27 08:35 UTC] yohgaki@php.net
Should have been won't fix
 [2003-01-10 12:32 UTC] norny at yahoo dot com
Now I'm getting a PHP notice in Windows XP using PHP 4.3.0 from the cmd line.

PHP Notice: ob_end_flush() [<a href='http://www.php.net/ref.outcontrol'>ref.outcontrol</a>]: failed to delete buffer default output handler. in C:\Apache\cgi-bin\mybot.php on line 58

In previous versions, ob_end_flush was my workaround to ob_implicit_flush not working. In 4.3.0 ob_end_flush isn't working for me and it does work in 4.2.3. Could someone make at least one of the two work again instead of keeping the "Won't fix" status?
 [2003-01-11 17:05 UTC] yohgaki@php.net
Since current output buffer is statelss even if some buffers need stateful handling to prevent crashes/malformed output/ etc.

Don't start buffer if you don't need it. Complain people who insisted this behavior. Search php-dev archive ;)

 [2003-01-11 17:08 UTC] yohgaki@php.net
And don't forget that some buffers should never be deleted once it's started. The error message is raised, since some users don't know it shouldn't.

 [2003-01-11 17:27 UTC] norny at yahoo dot com
We don't seem to be communicating very well. I've been wanting to shut off buffering this whole time. Your suggestion to not buffer if I don't need it is just telling me what I already want to do. I've been trying to use the functions documented in the manual that are supposed to shut it off, but they have a big "Won't fix" label on them in the bug database.

How about if I word it differently. I want the default buffer handling set in php.ini for my webpage output, but I don't want buffers for my command line scripts. I want those to output something to STDOUT as soon as it comes to a echo/print. If I don't use ob_end_flush, ob_implicit_flush, or ini_set, then what should I use to turn off buffering in my command line scripts.
 [2003-01-11 17:32 UTC] wez@php.net
As of PHP 4.3.0 you can use an alternative php.ini named:
php-{sapi}.ini, where {sapi} is the name of the sapi you are using.
So, for the cli, php will look for php-cli.ini before it tries php.ini.
For cgi it will look for php-cgi.ini etc.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 10:01:30 2024 UTC