On 23 Mar 2020, at 14:53, Ruediger Pluem <rpl...@apache.org> wrote: > To sum it up: > > ap_request_core_filter might setaside an EOR and data before this and return,
That’s normal. The core supports pipelining, meaning multiple requests, and therefore multiple EOR buckets can be lined up inside the core network filter (2.4) or any async filter (trunk). There is a safety check that doesn’t allow more than X EOR buckets (and therefore request pools) and no more than Y file buckets (and therefore file descriptors) in the pipeline at once, this triggers a block until capacity has been freed, but other than that, we’re fine so far. > but it is never called again, If we were in the event MPM we would be called again by the ap_run_output_pending() hook, which allows the request filters to be repeatedly called until all the filter stacks at all levels are empty: https://github.com/apache/httpd/blob/40d37b8a304f93cd14def4e9eab887b00a3d0e78/server/mpm/event/event.c#L1150 I see no call to ap_run_output_pending() in the worker MPM: https://github.com/apache/httpd/blob/trunk/server/mpm/worker/worker.c > because after EOR was > sent only connection and later filters (c->output_filters) are called > afterwards, but nothing before. 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. What happens if you set "AsyncFilter connection”? Does it skip the problem? Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
