[PHP-INTERNALS] function ob_gzhandler is missed in 5.4

i think / hope this is an accident

if the ob_functions(9 are replaced in any way this is not a doc-problem

it would be a major BC-break and destroy all my work of the last 10 years
rely on ob_start(), ob_get_contents(), ob_get_clean() and the fact
that multiple ob_start() can work inside another one as example to
include module-files using normal output-functions, buffer the output
and replace a palceholder in a template with the buffer while we are
in another template (site-template, list-templates, item-templates)

All the ob_* tests are still in 5.4 and they all pass, so no, these
functions have not been removed.

Hi:
<?php
var_dump(get_extension_funcs('zlib'));


result:

$ php54 /tmp/1.php
array(24) {
[0]=>
string(10) "readgzfile"
[1]=>
string(8) "gzrewind"
[2]=>
string(7) "gzclose"
[3]=>
string(5) "gzeof"
[4]=>
string(6) "gzgetc"
[5]=>
string(6) "gzgets"
[6]=>
string(7) "gzgetss"
[7]=>
string(6) "gzread"
[8]=>
string(6) "gzopen"
[9]=>
string(10) "gzpassthru"
[10]=>
string(6) "gzseek"
[11]=>
string(6) "gztell"
[12]=>
string(7) "gzwrite"
[13]=>
string(6) "gzputs"
[14]=>
string(6) "gzfile"
[15]=>
string(10) "gzcompress"
[16]=>
string(12) "gzuncompress"
[17]=>
string(9) "gzdeflate"
[18]=>
string(9) "gzinflate"
[19]=>
string(8) "gzencode"
[20]=>
string(8) "gzdecode"
[21]=>
string(11) "zlib_encode"
[22]=>
string(11) "zlib_decode"
[23]=>
string(20) "zlib_get_coding_type"

as we can see, the ob_gzhandler is missed in trunk.

thanks

I see these functions present in the current trunk:

ob_functions in current trunk/5.4 branch:

tyrael@chronos:~/checkouts/php-src/trunk$ ./sapi/cli/php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"

tyrael@chronos:~/checkouts/php-src/branches/PHP_5_4$ ./sapi/cli/php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"

ob functions in 5.3:

tyrael@chronos:~/checkouts/php-src/branches/PHP_5_4$ php -r
'var_dump(get_defined_functions());'|grep 'ob_'
string(12) "ob_gzhandler"
string(16) "ob_iconv_handler"
string(8) "ob_start"
string(8) "ob_flush"
string(8) "ob_clean"
string(12) "ob_end_flush"
string(12) "ob_end_clean"
string(12) "ob_get_flush"
string(12) "ob_get_clean"
string(13) "ob_get_length"
string(12) "ob_get_level"
string(13) "ob_get_status"
string(15) "ob_get_contents"
string(17) "ob_implicit_flush"
string(16) "ob_list_handlers"


as you can see, there is 2 functions gone in 5.4/trunk:
string(12) "ob_gzhandler"
string(16) "ob_iconv_handler"

thank your for confirming that

i only liked to get sure what happens early enough
the two missing are not soo bad but AFAIK also used from many
applications while i personally prerfer mod_deflate

Hi:
my mistake in the word usage, I mean ob_gzhandler missd,,

not ob_*,,

sorry

thanks

Indeed, I do not see ob_gzhandler in the function list, but no mention
of that in UPGRADING or other docs. As far as I understand, it was
converted from function to alias name, so function does not exist
anymore. Not sure if it was really needed, as the use case for it is now
covered by the alias.

Michael, as the patch committer, could you shed more light on this?

Personally, I do use ob_gzhandler as a function, so are some some other
projects :

http://www.google.com/codesearch#search/&q=lang:php "ob_gzhandler("

if the function could be reintroduced that would be cool...

Nicolas

Right, the PHP_FUNCTION ob_gzhandler has been removed and an alias
to the internal "zlib output compression" output handler has been
introduced, which is faster, can maintain a stateful context and
is cleanable as long as no output has been passed along.

What did people use ob_gzhandler for directly?

Mike

Hi!
Well, apparently they did for some reason, doing custom output handlers
based on it I guess. So the question is - is it possible to still have
this function implemented?

I'll try to hack up a replacement. It would definitely help if people
could post some exemplar test code to ensure it does what you expect it
to do...


Thanks,
Mike

Without a real ob_gzhandler function, replacing it with an alias as
currently in RC1 : what if someone then creates an ob_gzhandler function in
userland ? would ob_start('ob_gzhandler') use the userland function or
still the alias ? I think this is a second argument to make ob_gzhandler a
real function : least surprise.

Personally, I do use ob_gzhandler directly because it's the easiest way to
do chunked compressed encoding in userland.

This allows me to ask for compression as late as possible, because
registering an ob_start('ob_gzhandler'); may be too early for me. I do want
to choose to enable compression only when the very first byte is about to
be sent over the wire.

Hope it helps

Nicolas

<?php

function my_ob_handler($buffer, $mode)
{
// based on content-type,
// do some $buffer filtering
// and add some header()

if (/* content-type benefits compression based on some userland rules */)
{
$buffer = ob_gzhandler($buffer, $mode); // benefits from gzip
negotiation, chunked compression and related headers

if (PHP_OUTPUT_HANDLER_START & $mode)
{
// play/fix with Vary: header, as sent by ob_gzhandler or before
}
}

return $buffer;
}

Looks like a bad hack, but anyway, here's is another hack [1].

It's a patch for ext/zlib, which should make your hack work again...
whoever might find worth the hassle, may commit it... or insist
on me to do so...

Regards,
Mike

[1] http://dev.iworks.at/PATCHES/ob_gzhandler.diff.txt

Hi,

I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?

I put mike's patch and a comment to help track the BC break /potential
inconsistency :

https://bugs.php.net/bug.php?id=60326

Regards
Nicolas

On Fri, Nov 18, 2011 at 12:46, Nicolas Grekas
wrote:

Hi!
Ah, I didn't realize this is patch from Mike. Let me take another look
into it but I think it can be applied unless anyone sees anything wrong
with it.

Note that despite I wrote the patch, I'm -1 on it, as stated in the
previous message in this thread.

Regards,
Mike

Hi!
So what you prefer to do instead? I'd like to have ob_gzhandler(), but
if you think it can be done better way, please advise.

Sorry to insist, but taking the same argument in the thread for
REQUEST_TIME :

- x.y.z to x.y+1.z

What is the status of this ?

Looks like it's already been committed.

Regards,
Mike