On 06 Oct 2015, at 1:07 PM, Yann Ylavic <[email protected]> wrote:
> What I meant is that passing an empty brigade to a reinstate-able > filter may make it pass its data to the next filter, so we may want to > do this only on the first reinstate-able filter starting from > r->output_filters. If we did that we create the potential for filter starvation. The mod_cache filter is a classic case of this - it wants to call ap_filter_should_yield() to work out whether downstream is ready for more data, or whether it should just loop around and cache more data from the backend. But downstream is never ready for more data, because we stopped kicking filters when we got to mod_cache. The request hangs. The safest course of action to ensure we never second guess what a filter is trying to do is to kick all the eligible ones, once. Regards, Graham —
