On 3/31/20 6:52 PM, Yann Ylavic wrote:
> On Tue, Mar 31, 2020 at 7:35 AM Ruediger Pluem <[email protected]> wrote:
>>
>> On 3/31/20 1:19 AM, Yann Ylavic wrote:

>>
>> An idea would be a to have a filter that comes after all request filters 
>> (either as very first connection filter or in the same
>> position as the the ap_request_core_filter and as soon as it sees an EOS 
>> bucket it adds an EOR bucket afterwards.
>> For sync MPM's we would need an option to make ap_run_output_pending flush 
>> all data at least on request filter level.
> 
> This would potentially segfault a lot of output filters / handlers
> IMHO, what if we add EOR just after EOS, pass the whole to the core
> output filter which fails to write to the socket (ECONNRESET). The EOR
> gets destroyed, we return the error to the request filters/handlers
> which then shouldn't touch anything r->pool allocated. This includes
> the bb they used to pass their buckets for instance, so the usual
> ap_pass_brigade(r->output_filters, bb) + apr_brigade_cleanup(bb) would
> simply crash if bb = apr_brigade_create(r->pool, c->bucket_alloc)
> initially.

Good point. I missed the unwinding of the call stack after EOR was inserted.

Regards

RĂ¼diger

Reply via email to