Von: William A Rowe Jr <wr...@rowe-clan.net> Gesendet: Freitag, 20. Juli 2018 23:03 An: httpd <dev@httpd.apache.org> Betreff: Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/
On Fri, Jul 20, 2018, 15:22 Ruediger Pluem <mailto:rpl...@apache.org> wrote: BTW: We have the same load order issue issue with the following proxy modules: mod_proxy_connect mod_proxy_ftp mod_proxy_http mod_proxy_fcgi mod_proxy_scgi mod_proxy_fdpass mod_proxy_ajp mod_proxy_balancer mod_proxy_express > Correct. However this isn't a regression, and mod_proxy is an apparent > prerequisite to any of these, > which further and thankfully sorts first. The lbmethod providers differed in > all three respects. > Correct, but we are little bit lucky with the sort ordering here (or was it by design from the very beginning?) > It might be interesting to solve in a future enhancement release, but the > number of dependencies > likely makes this unrealistic. This is what I stumbled across. I found it kind of weird to add an APR_DECLARE_OPTIONAL_FN for ap_proxy_balancer_get_best_worker just after the PROXY_DECLARE for the same in mod_proxy.h. Later I understood why: We make the mod_proxy API accessible here via 2 different ways. I think mod_proxy is somewhat unique here as it seems to be the only module that is not always linked statically (like mod_core) that provides a high number of functions that are consumed by "sub"-modules. In case of other non core modules we usually encapsulate that via optional functions, provider interfaces or hooks. So probably also in the light of mod_proxy_http2 a review should be due how we can provide this API functionality in a less load dependent way. But I agree that it will be a huge, time consuming and disruptive (probably even unthankful) change. Regards Rüdiger
