> Am 04.02.2018 um 15:32 schrieb Jim Jagielski <j...@jagunet.com>: > > > >> 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.
No one wants to restrict any module's freedom to choose meaningful identifier for the data it manages. I think we are all in agreement to that. There seem to be two things worth discussion: 1. How can the default behaviour of mod_proxy_lb be changed, so that site owner with frequent reloads no longer suffer the current problems. I think we can get a solution without introducing a new directive. That would be good for our users. 2. Does httpd core expose a VirtualHost Identifier in its API and what would the semantic properties of such an identifier be? The second part is what I and Yann have both argued for. I do not know if we are in 100% agreement to what it should be, but we both seem to see use cases where an identifier (for me, an id always is unique) for a virtual host is useful. Again, I think that such a server id can be handed out by httpd without using a directive. That id does not have to satisfy all uses cases, since modules - as stated above - remain free to use it or come up with their own. Cheers, Stefan > > 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.
