Calling ob_clean() after ob_start('gz_handler') does not set Content-Encoding

[timint]

Description

The following code:

<?php

  ob_start('ob_gzhandler');
  ob_clean();
  
  echo 'Hello World';

Resulted in this output:

��� �H���W��/�I�V��J�

But I expected this output instead:

Hello World

There is no mention anywhere in the documentation that clearing the output buffer resets the Content-Encoding HTTP Header. If this is by design it should be stated, but it feels like an error.

PHP Version

PHP 8.0.10

Operating System

Windows 11 x64

[damianwadley]

ob_gzhandler isn't some special string that output buffering recognizes - it's an actual function - so it's not output buffering itself that is at fault. It's like you wrote your own callback that added a response header the first time it was called - that header will still be there after output buffering ends.

I think it would be possible for ob_gzhandler to detect the PHP_OUTPUT_HANDLER_CLEAN flag and to unset the header and reset back to the initial state. (Equally possible in userland.) Or to remove the header automatically if there's been no output, but that would mean no more effectively-empty responses with just the compression container and instead actually-empty responses with no content at all, but any good client should be totally okay with that.

[timint]

Yes, I'm a PHP developer since 15 years back. I know it's a callback function. What I don't get is why ob_clean() unsets the header when stackoverflow and PHP documentations is full of comments that ob_clean() does not affect headers.

Do you not see a problem with this?

[damianwadley]

Hmm, looks like I remembered ob_gzhandler backwards: it is a special string after all. It's an alias that goes through slightly different handling in that it will initialize a context, which ob_gzhandler the function does too but in a slightly different way. Thus why ob_start("ob_gzhandler") and ob_start(fn($buffer, $phase) => ob_gzhandler($buffer, $phase)); aren't the same.

Looking into it more, it's not that the headers are removed but that they aren't added at all. I'm also seeing odd behavior with a flush + clean in that the special "ob_gzhandler" issues a "Failed to delete buffer" notice while the wrapped ob_gzhandler() call does not.

So it seems like there's some iffy behavior with how it handles the CLEAN phases in general.

[timint]

Well done 👍

[cmb69]

I'm also seeing odd behavior with a flush + clean in that the special "ob_gzhandler" issues a "Failed to delete buffer" notice while the wrapped ob_gzhandler() call does not.

The special ob_gzhandler makes the handler immutable (i.e. uncleanable and unremoveable) after the headers have been sent. The wrapped ob_gzhandler doesn't do that. I'm not sure whether uncleanability is required, but at least the handler must be unremoveable, or otherwise output after removing the handler causes issues:

ob_start(fn($buffer, $phase) => ob_gzhandler($buffer, $phase));
echo "Hello";
ob_flush();
ob_end_clean();
echo "world";

Note to self: check ob_iconv_handler regarding these issues.

[cmb69]

check ob_iconv_handler regarding these issues.

Indeed, it has basically the same issue, namely that the Content-Type header is not properly set, if ob_clean() is called right after ob_start().

The "wrapper" issue isn't a thing, though, since ob_iconv_handler() isn't a real function, but only an ob handler alias.

[timint]

I just want to point out ob_clean() doesn't need to be right after. Any use of ob_clean() long after ob_start('gzhandler') should cause the same problem.

<?php

  ob_start('ob_gzhandler');

  ...

  echo 'Say something regretful';
  ob_clean();
  
  echo 'Hello World';

Result:

 ��� �H���W��/�I�V��J�

[cmb69]

I just want to point out ob_clean() doesn't need to be right after. Any use of ob_clean() long after ob_start('gzhandler') should cause the same problem.

Ah, right! More correctly, it is about calling ob_clean() before output has been flushed.

[timint]

Correct, that is how I stumbled upon this.