On Wed, Dec 20, 2023 at 10:43 AM Joe Orton <jor...@redhat.com> wrote: > > In the repro case you posted, only one brigade is passed by the handler, > with that I saw the "delayed last chunk" behaviour but not the Zlib > double-deinit error log. I think the Zlib error would only be triggered > by passing a second brigade with a FLUSH.
Ah, now that you mention it, that sounds right. That might have been another piece of context I had lost between writing the patches and sending them :) > > If I understand correctly, either patch would send the flush bucket after > > the last chunk marker and before the EOS bucket (i.e. [crlf last-chunk > > FLUSH EOS]), so there's no need for "userspace" to send an additional flush > > after the EOS bucket, and so mod_deflate wouldn't complain. Does that sound > > right? > > I don't think the mod_deflate patch fixed the "delayed last-chunk" > problem in my testing, but it is definitely correct & necessary to fix > the Zlib error as above. Right, I wasn't expecting the mod_deflate patch to fix the "delayed last-chunk" issue - by "either patch", I meant either your proposed chunk filter patch or my not-submitted-and-only-in-my-local-fork chunk filter patch. My understanding now is that my patch to mod_deflate makes it more robust, but the real underlying issue is the "delayed last-chunk" problem, which you're fixing.
