https://bz.apache.org/bugzilla/show_bug.cgi?id=59045
--- Comment #13 from Ruediger Pluem <[email protected]> --- (In reply to Yann Ylavic from comment #12) > (In reply to Ruediger Pluem from comment #11) > > > > Hm. Is another output filter really the best solution? It has to be passed > > for every run of the output chain. > > How about setting a note to c->notes in check_pipeline that informs > > mod_reqtimeout to step out of our way temporarily? This removes the need for > > mod_reqtimeout to second guess from other conditions that it has to step > > out. > > It's not really an heavy filter, not sure it performs slower than an > apr_table lookup... > This filter shouldn't be noticeable from a performance POV, and I think it > is sane in any case, do we (will) control all the speculative/non-blocking > (administrative) reads between requests? I admit that it might be a matter of taste. You can argue that you don't know where all these actions between requests happen and hence that in these cases the callers that pull from the input chain miss to set the note. Furthermore you can argue that the callers shouldn't need to know about mod_reqtimeout and the need to disable it and that they might forget to enable it again or disable it again if we do so automatically in mod_reqtimeout. On the other hand we had a fix for this issue already in 2.4.16 and did not capture all cases. Probably we missed other edge cases and need to add further more less complex code to detect them in mod_reqtimeout whereas in the notes case we would just need to set the note on callers side. > > The "notes" could possibly be added for individual modules (if needed) to > handle a temporary state (those that currently disable mod_reqtimeout > completely, for no good reason IMHO), but that's another story I think. > > But I'm not totally opposed to your solution either, maybe other opinions? No extraordinary strong feelings. Would love to hear the opinion of others. Maybe we should forward this to dev@ for discussion and make a decision based on this discussion which way to go. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
