On Mar 7, 2016 21:59, "Yehuda Katz" <yeh...@ymkatz.net> wrote: > > On Mon, Mar 7, 2016 at 9:06 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> On Mar 7, 2016 13:54, "Jan Kaluža" <jkal...@redhat.com> 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 ?192.170.2.1:80 # Use IP_FREEBIND to listen when IP is available (new behavior) > Listen +192.170.2.5:8000 # 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.
