> On Feb 2, 2018, at 8:05 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > That's a new directive too, very specialized (though it's your point). > Wouldn't it end up being declined to other modules one day or the other? > But mainly, rather than ignoring config changes, I think mod_proxy_lb > should ignore non-changes. > And it already knows how to do that provided the vhost's balancer id > does not change unnecessarily...
The main point is that modules are free to determine what they consider a unique Vhost; they are free to make whatever assumptions are required. Inevitably, it depends on the module and WHY it needs to know if a Vhost is "unique" and that will vary. Some will be more stringent, others more free. Creating a user land directive which is basically for internal module use doesn't help at all. The only issue is that *in this particular case* there is a weird use case where the assumption on what makes a Vhost unique doesn't match with what they want. One option, of course, is to say "Well, you need to figure out a way such that when you adjust the config file, the line number doesn't change". For such an extremely rare edge case, this seems a valid suggestion, rather than directly jumping into code and adding fluff and cruft that 99.9999% of httpd users will never want and see. But sometimes, such edge cases are not-so-rare enough that we provide code workaround for the normal case, ala the singular workaround directive suggested. It's specific, targeted and low touch for the vast majority of httpd users and admins. For example, consider the above. You say "I think mod_proxy_lb should ignore non-changes.". What do we do for the admin who doesn't feel that way? Or that we want ServerUID to be one thing for module foo and another for module bar? Isn't it up to the *module* itself to determine what makes sense? The module itself is (hopefully!! :) ) designed and architected and "logic" with its own specific assumption and requirement on what a unique UID needs to be. I would guess that 99.999% of the time, any change to that would cause really weird behavior. This just seems like a heavy-weight "fix" for an extremely weird on one-off edge case which is more suitably handled by, if an actual code change is really *required*, a small targeted patch.
