Gzip output handler - `ob_end_flush()` must not call `flush()`
まだ誰も着手していません。
- 主要言語
- C
- スター
- 40.4k
- フォーク
- 8.1k
- 平均マージ
- 2日 13時間
- マージ済み PR(30日)
- 96
説明
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
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
提供された PHP CLI コマンドで動作を再現し、空の出力バッファと出力を含むバッファを比較して、ヘッダーを引き続き送信できるか確認します。次に ob_end_flush() のパスと zlib 出力ハンドラーを調査します。空のバッファでは暗黙的に flush されず、空でない出力では期待される動作が維持されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- c, php
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100