> Am 09.01.2020 um 11:32 schrieb Pluem, Ruediger, Vodafone Group
> <ruediger.pl...@vodafone.com>:
>
>
>
>
> C2 General
>
>> -----Ursprüngliche Nachricht-----
>> Von: Yann Ylavic <ylavic....@gmail.com>
>> Gesendet: Mittwoch, 8. Januar 2020 16:48
>> An: httpd-dev <dev@httpd.apache.org>
>> Betreff: Re: worker MPM test failures (was Re: Still Failing:
>> apache/httpd#190 (trunk - 894b6a1))
>>
>> On Wed, Jan 8, 2020 at 8:36 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>>
>>> Just for my further analysis let me try to get the purpose of the
>>> ap_request_core_filter:
>>>
>>> It should leverage at least parts of the benefits of the filter
>> setaside / yielding / brigade reinstate framework for
>>> filters that do not use this, because e.g.
>>>
>>> - they are not aware of this framework
>>
>> Yes, the goal (I think, Graham could confirm) is to let request
>> filters work as before but have a catch all (last) filter to not let
>> morphing buckets go through connection filters (and consume c->pool).
>> Same for setasides.
>>
>>> - it seems to complex for them to use it and adjust their filter
>>>
>>> Of course this is not perfect as some resource and content filters
>> need to handle this on their own e.g. deflate when
>>> compressing contents of file buckets in order to avoid blocking
>> writes.
>>
>> Correct.
>>
>>>
>>> Thinking out loudly a bit here: Except for ap_request_core_filter all
>> other resource and content filters should process
>>> all the data they might have setaside when they see an EOS in a
>> brigade, correct?
>>
>> I think so, because otherwise they will never be called again since
>> the core/mpm only cares about connection filters, so the data must be
>> there after EOS. In any case, request filters shall not be called when
>> EOR is in the place.
>>
>>
>> Regarding my patch, I'm afraid it's not the right fix, we can't front
>> push several req_core output filters like this.
>> If an old/outer req_core filter has to setaside buckets (network
>> EAGAIN) while the passed brigade contains buckets from the new
>> request, then it will setaside the buckets from a newer request pool
>> to an oldest's.
>> Even though it can (possibly) work, it does not look quite optimal,
>> we'd need some kind of Start Of Request (SOR) bucket to delimit
>> buckets from/for successive requests. SOR would be passed through
>> c->output_filters when a new request is created (e.g. in
>> http_create_request()), since anything sent through the request
>> filters from that time should be about this last request.
>> Then a single req_core connection filter could be responsible for
>> setting aside buckets on the relevant request pool (should some
>> congestion occur).
>>
>> Dunno if we want to go that route, though...
>
> As this looks like to be a larger amount of work I come back to my simple
> patch idea
> that would possibly cause more blocking writes, but would ensure that the
> data is sent
> completely at least. Basically it pushes all down the chain once it notices
> an EOR bucket.
> See
>
> https://github.com/apache/httpd/pull/88
>
> 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.
