On Fri, Mar 27, 2020 at 11:54 AM Graham Leggett <[email protected]> wrote: > > We need to find the reason that in a non-async case, data is being setaside, > and we need to fix it.
Connection and network output filters shouldn't care about async or not, they just feed the pipe as much as possible, and setaside what they can't (up to reinstate limits). For non-async this is pipelining, let's not disable that. For non-async (though async would also benefit from it), what we need to do is make sure that each request (worth handling in httpd) gets finally EOR-ed, so that it's accounted (pipelining for non-async, or blocking for async). The bug in the current code is about ap_request_core_filter() retaining data (because core should_yield) and returning, but not getting called again (because it's not a connection filter and the core and MPMs care only about that). Whether ap_request_core_filter() should block depending on async/non-async does not matter IMHO. Regards, Yann.
