httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: New ServerUID directive
Date Sun, 04 Feb 2018 14:32:38 GMT

> On Feb 2, 2018, at 8:05 PM, Yann Ylavic <> 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.

View raw message