Req #23877 [Com]: ob_implicit_flush does not work
Edit report at https://bugs.php.net/bug.php?id=23877&edit=1
ID: 23877
Comment by: valentiny510 at yahoo dot es
Reported by:sthomas at townnews dot com
Summary:ob_implicit_flush does not work
Status: Not a bug
Type: Feature/Change Request
Package:CGI/CLI related
Operating System: Redhat Linux
PHP Version:4.3.2
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Aleluya Mike, Thank you... (just hope that sthomas did't died after all this
time :)
Previous Comments:
[2013-07-30 19:19:54] m...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
"output call" does not refer to echo/print but to a call to the SAPI's module
ub_write function.
[2013-03-20 01:09:19] valentiny510 at yahoo dot es
Related To: Bug #64460
[2009-11-11 22:59:19] haakon at avelia dot no
According to the manual:
"ob_implicit_flush() will turn implicit flushing on or off. Implicit flushing
will result in a flush operation after every output call, so that explicit
calls to flush() will no longer be needed."
This means that if I have registered a output-handler like this:
function myhandler($str) {
// handle $str internally
}
ob_start('myhandler');
ob_implicit_flush(true);
Then according to the manual, each time I call "echo", "print" or output data
outside PHP tags; it should call the ob_handler callback.
This does not work in PHP CLI mode.
If this is not expected to work, the manual should be updated. But this is a
feature i really need, since i want to be able to let people write "print/echo"
in their scripts, but my handler should preprocess the data.
IMHO, it would have been really nice if this function worked as the
documentation says. Either by actually automatically firing flush() on each
echo/print/etc, or by implicitly calling the callback on each echo/print/etc.
[2005-07-19 14:40:29] jeff at tillwicks dot us
I agree with sthomas totally on this. I have been promised that there is a way
to get the output preformance of perl with php using output buffering and
flush. I use the cli version and have yet to get it working once. I have
followed every example (copy and pasted exact) that is featured in php's own
documentation. With every attempt all data is sent after the entire page has
finished loading. It is just lack of support on this issue.
[2004-07-22 11:16:48] everyone at example dot com
Look dude, you don't have to be so damn obnoxious about it. Be a bit more
polite and you will get a more favorable response.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=23877
--
Edit this bug report at https://bugs.php.net/bug.php?id=23877&edit=1
#23877 [Com]: ob_implicit_flush does not work
ID: 23877
Comment by: haakon at avelia dot no
Reported By: sthomas at townnews dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Redhat Linux
PHP Version: 4.3.2
New Comment:
According to the manual:
"ob_implicit_flush() will turn implicit flushing on or off. Implicit
flushing will result in a flush operation after every output call, so
that explicit calls to flush() will no longer be needed."
This means that if I have registered a output-handler like this:
function myhandler($str) {
// handle $str internally
}
ob_start('myhandler');
ob_implicit_flush(true);
Then according to the manual, each time I call "echo", "print" or
output data outside PHP tags; it should call the ob_handler callback.
This does not work in PHP CLI mode.
If this is not expected to work, the manual should be updated. But this
is a feature i really need, since i want to be able to let people write
"print/echo" in their scripts, but my handler should preprocess the
data.
IMHO, it would have been really nice if this function worked as the
documentation says. Either by actually automatically firing flush() on
each echo/print/etc, or by implicitly calling the callback on each
echo/print/etc.
Previous Comments:
[2005-07-19 14:40:29] jeff at tillwicks dot us
I agree with sthomas totally on this. I have been promised that there
is a way to get the output preformance of perl with php using output
buffering and flush. I use the cli version and have yet to get it
working once. I have followed every example (copy and pasted exact)
that is featured in php's own documentation. With every attempt all
data is sent after the entire page has finished loading. It is just
lack of support on this issue.
[2004-07-22 11:16:48] everyone at example dot com
Look dude, you don't have to be so damn obnoxious about it. Be a bit
more polite and you will get a more favorable response.
[2003-06-30 11:05:43] sthomas at townnews dot com
Implicit flush is turned off in the php.ini file, but that's only the
default status. Calling ob_implicit_flush should enable autoflushing.
The CLI *does* work if I set the output_buffering setting to 0, but
here's the screwy part: Set it to any non-zero value, and flushing
doesn't occur at all.
Setting output_buffering to 1024 would imply that after 1024 characters
are sent to the buffer, the buffer is sent to screen/browser. This is
not the case. So not only is ob_implict_flush completely ignored when
output_buffering is set to a non-zero value, but output_buffering
doesn't flush after the designated value either. At least not with the
CLI.
But don't take my word for it. Set output_buffering to *anything*
above 0, then run this script with the CLI:
You'll see that no flushing is taking place... at all. Even with an
explicit call to flush(), and even though ob_implicit_flush says that
output buffering should now be disabled. Yes ob_end_flush() works,
however the PHP documentation says ob_implicit_flush does an implied
call to ob_end_flush(). So either the documentation is wrong, or PHP is
broken. If the documentation is wrong, why have ob_implicit_flush in
the first place if it doesn't actually do anything?
Because so far with recent versions of PHP, I haven't been able to
create a single test case where ob_implicit_flush actually did anything.
[2003-06-30 09:33:08] m...@php.net
There's a second level of buffering after the ob_ buffering. What is
your implicit_flush setting? Please also refer to
http://www.php.net/flush
[2003-06-30 08:02:09] sthomas at townnews dot com
So... did you read the report at all? Did you see the part where I
quoted the PHP documentation? Let me do it again:
"Turning implicit flushing on will disable output buffering, the output
buffers current output will be sent as if ob_end_flush() had been
called."
Therefore, according to this, calling ob_implicit_flush *IMPLIES A CALL
TO OB_END_FLUSH*! What part of YOUR OWN DOCUMENTATION do you not
understand? Either the documentation is wrong, or PHP is wrong.
Whichever it is, fix it so there's at least some consistancy.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23877
--
Edit this bug report at http://bugs.php.net/?id=23877&edit=1
#23877 [Com]: ob_implicit_flush does not work
ID: 23877 Comment by: jeff at tillwicks dot us Reported By: sthomas at townnews dot com Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux PHP Version: 4.3.2 New Comment: I agree with sthomas totally on this. I have been promised that there is a way to get the output preformance of perl with php using output buffering and flush. I use the cli version and have yet to get it working once. I have followed every example (copy and pasted exact) that is featured in php's own documentation. With every attempt all data is sent after the entire page has finished loading. It is just lack of support on this issue. Previous Comments: [2004-07-22 11:16:48] everyone at example dot com Look dude, you don't have to be so damn obnoxious about it. Be a bit more polite and you will get a more favorable response. [2003-06-30 11:05:43] sthomas at townnews dot com Implicit flush is turned off in the php.ini file, but that's only the default status. Calling ob_implicit_flush should enable autoflushing. The CLI *does* work if I set the output_buffering setting to 0, but here's the screwy part: Set it to any non-zero value, and flushing doesn't occur at all. Setting output_buffering to 1024 would imply that after 1024 characters are sent to the buffer, the buffer is sent to screen/browser. This is not the case. So not only is ob_implict_flush completely ignored when output_buffering is set to a non-zero value, but output_buffering doesn't flush after the designated value either. At least not with the CLI. But don't take my word for it. Set output_buffering to *anything* above 0, then run this script with the CLI: You'll see that no flushing is taking place... at all. Even with an explicit call to flush(), and even though ob_implicit_flush says that output buffering should now be disabled. Yes ob_end_flush() works, however the PHP documentation says ob_implicit_flush does an implied call to ob_end_flush(). So either the documentation is wrong, or PHP is broken. If the documentation is wrong, why have ob_implicit_flush in the first place if it doesn't actually do anything? Because so far with recent versions of PHP, I haven't been able to create a single test case where ob_implicit_flush actually did anything. [2003-06-30 09:33:08] [EMAIL PROTECTED] There's a second level of buffering after the ob_ buffering. What is your implicit_flush setting? Please also refer to http://www.php.net/flush [2003-06-30 08:02:09] sthomas at townnews dot com So... did you read the report at all? Did you see the part where I quoted the PHP documentation? Let me do it again: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Therefore, according to this, calling ob_implicit_flush *IMPLIES A CALL TO OB_END_FLUSH*! What part of YOUR OWN DOCUMENTATION do you not understand? Either the documentation is wrong, or PHP is wrong. Whichever it is, fix it so there's at least some consistancy. [2003-06-29 21:07:05] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You should've used ob_end_flush(); instead of ob_implicit_flush();. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23877 -- Edit this bug report at http://bugs.php.net/?id=23877&edit=1
#23877 [Com]: ob_implicit_flush does not work
ID: 23877 Comment by: everyone at example dot com Reported By: sthomas at townnews dot com Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux PHP Version: 4.3.2 New Comment: Look dude, you don't have to be so damn obnoxious about it. Be a bit more polite and you will get a more favorable response. Previous Comments: [2003-06-30 11:05:43] sthomas at townnews dot com Implicit flush is turned off in the php.ini file, but that's only the default status. Calling ob_implicit_flush should enable autoflushing. The CLI *does* work if I set the output_buffering setting to 0, but here's the screwy part: Set it to any non-zero value, and flushing doesn't occur at all. Setting output_buffering to 1024 would imply that after 1024 characters are sent to the buffer, the buffer is sent to screen/browser. This is not the case. So not only is ob_implict_flush completely ignored when output_buffering is set to a non-zero value, but output_buffering doesn't flush after the designated value either. At least not with the CLI. But don't take my word for it. Set output_buffering to *anything* above 0, then run this script with the CLI: You'll see that no flushing is taking place... at all. Even with an explicit call to flush(), and even though ob_implicit_flush says that output buffering should now be disabled. Yes ob_end_flush() works, however the PHP documentation says ob_implicit_flush does an implied call to ob_end_flush(). So either the documentation is wrong, or PHP is broken. If the documentation is wrong, why have ob_implicit_flush in the first place if it doesn't actually do anything? Because so far with recent versions of PHP, I haven't been able to create a single test case where ob_implicit_flush actually did anything. [2003-06-30 09:33:08] [EMAIL PROTECTED] There's a second level of buffering after the ob_ buffering. What is your implicit_flush setting? Please also refer to http://www.php.net/flush [2003-06-30 08:02:09] sthomas at townnews dot com So... did you read the report at all? Did you see the part where I quoted the PHP documentation? Let me do it again: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Therefore, according to this, calling ob_implicit_flush *IMPLIES A CALL TO OB_END_FLUSH*! What part of YOUR OWN DOCUMENTATION do you not understand? Either the documentation is wrong, or PHP is wrong. Whichever it is, fix it so there's at least some consistancy. [2003-06-29 21:07:05] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You should've used ob_end_flush(); instead of ob_implicit_flush();. [2003-05-29 15:51:03] sthomas at townnews dot com Please note that the manual says this: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Now, I've set output_buffering = 0 in my php.ini script, so supposedly ob_implicit_flush will flush any buffers started by the script itself, and continue flushing output thereafter. Try this: This script will not output "Hi!" after each iteration through the loop. Supposedly the documented behavior of ob_implicit_flush is to flush all output buffers once it's called, and disable output buffering for further statements that produce output (print, etc.) So either the documentation is wrong, or there's a bug in ob_implicit_flush. You decide. -- Edit this bug report at http://bugs.php.net/?id=23877&edit=1
#23877 [Com]: ob_implicit_flush does not work
ID: 23877 Comment by: pclark4 at austin dot rr dot com Reported By: sthomas at townnews dot com Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux PHP Version: 4.3.2 New Comment: when i try and play games or check my mail in yahoo is says brouser refuses to log in (rejected cookies Previous Comments: [2003-06-30 11:05:43] sthomas at townnews dot com Implicit flush is turned off in the php.ini file, but that's only the default status. Calling ob_implicit_flush should enable autoflushing. The CLI *does* work if I set the output_buffering setting to 0, but here's the screwy part: Set it to any non-zero value, and flushing doesn't occur at all. Setting output_buffering to 1024 would imply that after 1024 characters are sent to the buffer, the buffer is sent to screen/browser. This is not the case. So not only is ob_implict_flush completely ignored when output_buffering is set to a non-zero value, but output_buffering doesn't flush after the designated value either. At least not with the CLI. But don't take my word for it. Set output_buffering to *anything* above 0, then run this script with the CLI: You'll see that no flushing is taking place... at all. Even with an explicit call to flush(), and even though ob_implicit_flush says that output buffering should now be disabled. Yes ob_end_flush() works, however the PHP documentation says ob_implicit_flush does an implied call to ob_end_flush(). So either the documentation is wrong, or PHP is broken. If the documentation is wrong, why have ob_implicit_flush in the first place if it doesn't actually do anything? Because so far with recent versions of PHP, I haven't been able to create a single test case where ob_implicit_flush actually did anything. [2003-06-30 09:33:08] [EMAIL PROTECTED] There's a second level of buffering after the ob_ buffering. What is your implicit_flush setting? Please also refer to http://www.php.net/flush [2003-06-30 08:02:09] sthomas at townnews dot com So... did you read the report at all? Did you see the part where I quoted the PHP documentation? Let me do it again: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Therefore, according to this, calling ob_implicit_flush *IMPLIES A CALL TO OB_END_FLUSH*! What part of YOUR OWN DOCUMENTATION do you not understand? Either the documentation is wrong, or PHP is wrong. Whichever it is, fix it so there's at least some consistancy. [2003-06-29 21:07:05] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You should've used ob_end_flush(); instead of ob_implicit_flush();. [2003-05-29 15:51:03] sthomas at townnews dot com Please note that the manual says this: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Now, I've set output_buffering = 0 in my php.ini script, so supposedly ob_implicit_flush will flush any buffers started by the script itself, and continue flushing output thereafter. Try this: This script will not output "Hi!" after each iteration through the loop. Supposedly the documented behavior of ob_implicit_flush is to flush all output buffers once it's called, and disable output buffering for further statements that produce output (print, etc.) So either the documentation is wrong, or there's a bug in ob_implicit_flush. You decide. -- Edit this bug report at http://bugs.php.net/?id=23877&edit=1
