> Am 04.05.2016 um 11:09 schrieb Graham Leggett <[email protected]>: > > On 04 May 2016, at 10:45 AM, Stefan Eissing <[email protected]> > wrote: > >> I have been wrong before...but... >> >> mod_http2 needs to send out a file response: >> 1. it starts with the response body brigade: [file:0-len][eos] >> 2. it sends the first 16K frame by splitting the file bucket: >> -> passing to core output: [heap:frame header][file:0-16k] >> -> remaining body: [file:16K-len][eos] >> 3. core_output decides to setaside: >> -> setaside (deferred pool): [heap:frame header][file:0-16k] >> -> remaining body: [file:16K-len][eos] >> 4. core_output sends and, sometimes, clears the deferred pool >> -> which closes the file descriptor >> 5. next 16K frame: [heap:frame header][file:16k-32K] results in APR_EBADF > > This smells wrong - if you split a file bucket (and there is nothing wrong > with splitting a file bucket) you should end up with two file buckets, and > destroying the first file bucket while the second file bucket still exists > shouldn’t cause the second file bucket descriptor to close.
The problem is not the apr_bucket_destroy(). The file bucket setaside, calls apr_file_setaside(), in core_output on a deferred pool, and then core_output clears that pool. This invalidates all still existing file buckets using that apr_file. At least, that is my reading of what happens. > Regards, > Graham > — >
