php / php/php-src

Gzip output handler - `ob_end_flush()` must not call `flush()`

Open
#13,798 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug Category: Output Extension: zlib Status: Needs Triage
Dominant language
C
Stars
40.4k
Forks
8.1k
Avg merge
2d 13h
Merged PRs (30d)
96

Description

Description

This issue is problematic only when zlib.output_compression is enabled.

Currently, when zlib.output_compression is enabled like:

php -S 127.0.0.1:81 -d zlib.output_compression=1 -t .

(but also tested if enabled when used /w Apache /wo mod_deflate)

and ob_end_flush() is called, no headers cannot be send anymore even if the nothing was output.

Currently, we had to use the following code

while (ob_get_level() > 0) {
    if (ob_get_length() === 0) {
        ob_end_clean();
    } else {
        ob_end_flush();
    }
}

to workaround.

When zlib.output_compression is NOT enabled, the following code:

while (ob_get_level() > 0) {
    ob_end_flush();
}

is working (allows to send additional headers).

Because of this inconsistency, I belive php gzip output handler behaviour should be fixed, when output buffer is empty, to not flush implicitly.

PHP Version

any

Operating System

any

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior with the provided PHP CLI command, comparing an empty output buffer with one containing output and checking whether headers can still be sent. Then inspect the ob_end_flush() path and the zlib output handler; done means an empty buffer does not implicitly flush while non-empty output retains its expected behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, php
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.