httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: [PATCH] Add "FreeListen" to support IP_FREEBIND
Date Tue, 08 Mar 2016 05:32:50 GMT
On Mar 7, 2016 21:59, "Yehuda Katz" <> wrote:
> On Mon, Mar 7, 2016 at 9:06 PM, William A Rowe Jr <>
>> On Mar 7, 2016 13:54, "Jan Kalu┼ża" <> wrote:
>> >
>> > On 03/07/2016 04:17 PM, Jim Jagielski wrote:
>> >>
>> >> Intstead of adding YAD (yet another directive ;) ), would it
>> >> be possible to somehow leverage Listen itself, maybe with some
>> >> sort of flag?
>> >
>> >
>> > Yes, that would be quite possible. I was thinking about that way, but
I have chosen YAD as a first approach. If you think adding flag to Listen
is better way, I can rework my patch.
>> >
>> > Regards,
>> > Jan Kaluza
>> >
>> Reviewing the behavior, an unadorned new directive makes more sense to
me than cluttering Listen, which already takes one optional protocol
behavior argument.
>> The same handler can process both directives.
> A benefit of using a flag is: what happens if the default changes at some
point? YAD would need to be created to go back to the old behavior - which
would make things more complicated.  Is it possible to use something like a
plus/minus or question mark symbol with each address:port which would allow
the default to be changed at some future point without requiring having
this discussion again?
> Example:
> Listen ?  # Use IP_FREEBIND to listen when IP is available
(new behavior)
> Listen +  # Require IP to be available (old behavior)
> Listen [2001:db8::a00:20ff:fea7:ccea]:80  # Current default behavior (old)

Interesting point, I raised the same consideration for piped logging syntax
some years ago.  But at that time it was the consensus that the default
would change with the next major version.

I see small probably that this would become a default behavior, from the
perspective of robustness alone.  I see that you simply suggest a tri-state
(and trailing '?' Vs '!' makes more intuitive sense to me), but I'm not
seeing a consensus yet that the default would change in the future.

The same can be accomplished by adding a third 'FixedListen' directive,
leaving Listen itself free to switch behaviors.

But from the migration perspective, I'd be loath to switch any default
Listen behavior without the admin's explicit intervention.  POLS.

View raw message