On Wed, Jan 8, 2020 at 8:36 AM Ruediger Pluem <[email protected]> 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... Regards, Yann.
