ID:               16676
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Bogus
+Status:           Won\'t fix
 Bug Type:         Output Control
 Operating System: Slackware 8.0
 PHP Version:      4.2.0
 New Comment:

Should have been won't fix


Previous Comments:
------------------------------------------------------------------------

[2002-12-27 08:16:53] [EMAIL PROTECTED]

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-24 21:39:37] [EMAIL PROTECTED]

You can solve your problem by putting @ob_end_flush(); on top of your
command line scripts.

------------------------------------------------------------------------

[2002-12-24 16:25:58] [EMAIL PROTECTED]

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-09-26 16:47:23] [EMAIL PROTECTED]

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-04-18 11:34:07] [EMAIL PROTECTED]

> 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.

------------------------------------------------------------------------

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/16676

-- 
Edit this bug report at http://bugs.php.net/?id=16676&edit=1

Reply via email to