> Am 09.01.2020 um 12:39 schrieb Pluem, Ruediger, Vodafone Group
> <[email protected]>:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing <[email protected]>
>> Gesendet: Donnerstag, 9. Januar 2020 11:51
>> An: [email protected]
>> Betreff: Re: worker MPM test failures (was Re: Still Failing:
>> apache/httpd#190 (trunk - 894b6a1))
>>
>>
>>
>>> Am 09.01.2020 um 11:32 schrieb Pluem, Ruediger, Vodafone Group
>> <[email protected]>:
>>>
>>>
>>> BTW: Can we really have morphing buckets in ap_request_core_filter?
>> ap_request_core_filter runs
>>> after a possible HTTP chunking filter that I guess needs to be in
>> place when we have a morphing
>>> bucket which makes it impossible to determine the content length
>> upfront. Hence I guess the
>>> HTTP chunking filter will transform all these morphing buckets
>> already.
>>> Or is this just a safety measure to support other protocols but HTTP?
>>
>> What exactly do you mean by a "morphing" bucket? If that include file
>> buckets, then I guess "yes" is the answer.
>>
>
> A file bucket is not a the morphing bucket I am talking here about
> although it morphs as well when read, because it has a known length.
> A morphing bucket has a length of -1 and when it is read it "morphs"
> into a bucket of known length (mostly in memory) with a subset of the
> content of the morphing bucket and the morphing bucket is added back
> in the brigade after the morphed bucket sans the content left in the morphed
> bucket.
> Examples are
>
> CGI buckets
> PIPE buckets
> Socket buckets
Thanks for the clarification. I agree that all those should have been resolved
to a known length in the core filters before a setaside.
>
> Regards
>
> Rüdiger
