On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski wrote:
>
> On Feb 5, 2018, at 7:38 AM, Stefan Eissing
> wrote:
>
> 2. Does httpd core expose a VirtualHost Identifier in its API and
> what would the semantic properties of such an identifier be?
>
> Yes, it does. It's the server_rec. That contains
IMO, unless there are issues/problems with what we do *now*,
we shouldn't be changing things...
> On Feb 6, 2018, at 2:24 AM, Yann Ylavic wrote:
>
> On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski wrote:
>>
>> On Feb 5, 2018, at 7:38 AM, Stefan Eissing
>> wrote:
>>
>> 2. Does httpd core expose
It depends on what you do now, but if it's "reload the server with any
change before the vhost" than there is an issue.
You'd lose SHMs, persisted files, all the vhost's balancers states...
On Tue, Feb 6, 2018 at 2:29 PM, Jim Jagielski wrote:
> IMO, unless there are issues/problems with what we d
With my proposal, this is lost only if IP:port(s) or
ServerName/Alias(s) change, which is already a win and shouldn't
change the way each balancer is bound to its vhost (i.e. a request on
a vhost wouldn't be accounted/handled by a lb on another vhost).
On Tue, Feb 6, 2018 at 3:18 PM, Yann Ylavic
On Tue, Feb 6, 2018 at 9:23 AM, Yann Ylavic wrote:
> With my proposal, this is lost only if IP:port(s) or
> ServerName/Alias(s) change, which is already a win and shouldn't
> change the way each balancer is bound to its vhost (i.e. a request on
> a vhost wouldn't be accounted/handled by a lb on an
On Tue, Feb 6, 2018 at 3:33 PM, Eric Covener wrote:
> On Tue, Feb 6, 2018 at 9:23 AM, Yann Ylavic wrote:
>> With my proposal, this is lost only if IP:port(s) or
>> ServerName/Alias(s) change, which is already a win and shouldn't
>> change the way each balancer is bound to its vhost (i.e. a reques
On Tue, Feb 6, 2018 at 9:48 AM, Yann Ylavic wrote:
> On Tue, Feb 6, 2018 at 3:33 PM, Eric Covener wrote:
>> On Tue, Feb 6, 2018 at 9:23 AM, Yann Ylavic wrote:
>>> With my proposal, this is lost only if IP:port(s) or
>>> ServerName/Alias(s) change, which is already a win and shouldn't
>>> change
I don't think it does.
> On Feb 6, 2018, at 9:18 AM, Yann Ylavic wrote:
>
> It depends on what you do now, but if it's "reload the server with any
> change before the vhost" than there is an issue.
> You'd lose SHMs, persisted files, all the vhost's balancers states...
>
> On Tue, Feb 6, 2018
> Am 06.02.2018 um 16:14 schrieb Jim Jagielski :
>
> I don't think it does.
I do not understand. I feel that I am missing something here.
You're saying that the scenario does not exist or that it does not trigger the
described effect?
>> On Feb 6, 2018, at 9:18 AM, Yann Ylavic wrote:
>>
>
On Tue, Feb 6, 2018 at 6:17 PM, Stefan Eissing
wrote:
>
>
>> Am 06.02.2018 um 16:14 schrieb Jim Jagielski :
>>
>> I don't think it does.
>
> I do not understand. I feel that I am missing something here.
>
> You're saying that the scenario does not exist or that it does not trigger
> the described
Just for fun, what is the functional difference, if any, between this
very large patch, that adds lots of code, and this extremely simple
diff which, from what I can tell, handles the exact defined
"problem" with the original code???
Just curious if our current policy is to use a sledgehammer now
On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski wrote:
> Just for fun, what is the functional difference, if any, between this
> very large patch, that adds lots of code, and this extremely simple
> diff which, from what I can tell, handles the exact defined
> "problem" with the original code???
Th
On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski wrote:
>
> Just curious if our current policy is to use a sledgehammer now
> to fix what can be handled with a pair of tweezers.
Btw, I also think this is a sledgehammer for the mod_proxy_lb case,
while it wouldn't for s->server_id (IMHO).
At this point, I no longer have a horse in this race... From a philosophical
point of view, adding 10kgs of fluff to fix 1kg of error seems over-engineering
to me, but that is just me.
+1 for whatever you think is best... and thx for your
work on this.
14 matches
Mail list logo
