>>717
一応こちらの現時点の結論を言っておくと、
Content-Lengthはストリーミング以外は全部つけないと駄目だな。RFCでもSHOULDだし、
https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2
動きを見る限り、apacheもこれをスヌープしてる。
よって、「仕様準拠」なら flush() だけで何も問題ないから、
fastcgi_finish_requestはモジュール化した際に廃止された、と見える。

だから711内のページ筆者もだいぶ間違ってて、
まずConnection: closeをTCP接続終了（いわゆるFIN/FINACK/ACK)と勘違いしてるが、
実際はこれは同じコネクションを再利用するかの話だから関係ないし、
HTTP/1.1だとデフォでkeep-aliveなので無駄にcloseにするとバグに当たる可能性があるから悪手だ。
https://en.wikipedia.org/wiki/HTTP_persistent_connection#HTTP_1.1
そしてContent-Lengthを付けたら上手く行くよ！ではなく、付けないと話にならなくて、
仕様準拠＝付けてれば最初からこんな事にはならずに済んでる。
だからこいつも俺も『仕様を知っている者から見れば』ただのマッチポンプでしかない。

ここで711内ページ筆者、俺、或いは君らも含めての問題は、レイヤーを間違ってることだ。
PHPは生のヘッダを普通に扱えるレイヤーでのプログラミングになるから、ヘッダについての仕様を(本来は)熟知してないといけない。
だから575に対してはいきなり「Content-Lengthヘッダ付けろ馬鹿タレ」とぶった切れないといけない。
とはいえ昨今の状況であらゆる階層の仕様を熟知しろなんてどだい無理な話ではあるが。

だからやっぱりもう一つレイヤーを上げるべきなんだ。
ヘッダの知識がない状態で具だけ書きたいのなら、ヘッダ周りを自動的によしなにやってくれるフレークワークを使うべきだろう。
そしてLaravelは見たところそんな感じだ。
なるほど、「セッション周りとかはフレームワークに任せてLaravelだけ使ってろ」というのは当たってる。
(俺も含めて）素人ほどフレームワークを使うべきだろう。

とはいえ、俺はデプロイ先が無料サーバなのでいちいち仕様確認して素PHPレイヤでのプログラミングをするしかないのだが。