On 24 Mar 2020, at 11:47, Joe Orton <jor...@redhat.com> wrote:

> On Tue, Mar 24, 2020 at 12:35:45AM +0200, Graham Leggett wrote:
>> The most likely reason is because:
>> a) http://httpd.apache.org/docs/trunk/mod/core.html#asyncfilter defaults to 
>> request, meaning request filters are expected to support async filters; and
>> b) the worker MPM doesn't call the ap_run_output_pending() hook, and 
>> so by definition does not support async filters.
>> The fix (as far as I can see) is for the worker MPM to run the 
>> ap_run_output_pending() hook.
> Only 3/8 trunk MPMs have that call, so those are all broken right now?  
> I know we have seen this fail for both prefork and worker in Travis.

They shouldn't be broken, because only 3/8 trunk MPMs declare that they support 

>> What happens if you set "AsyncFilter connection”? Does it skip the problem?
> Are you unable to repro using the script I posted in the thread Ruediger 
> referenced to confirm?

Not without a lot of retooling in my builds in the middle of an office move 
with no notice ahead of a pending countrywide shutdown, so no alas.

>  If this is the correct default I guess I'd ask 
> why isn't this hard-coded - at least maybe for affected MPMs?  Maybe try 
> it and see if the Travis failures go away.

It is not the correct default, no.

What it does do is work around buggy request filters (set it to connection) or 
buggy connection filters (set it to network and get 2.4 behaviour)..

Set AsyncFilter appropriately and you’ll at least narrow it down.

The question you’re asking is “why is is an async path being taken when 
AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should be noops in 
this situation.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to