[PATCH] ignore ipv6=off resolver option when no ipv6 support
thibaultcha at fastmail.com
Fri Dec 16 19:35:44 UTC 2016
On 12/16/16 7:07 AM, Maxim Dounin wrote:
> Builds without IPv6 support is something we are phasing out.
> Starting with nginx 1.11.5 IPv6 support is automatically
> configured as long as supported by OS:
> Changes with nginx 1.11.5, 11 Oct 2016:
> *) Change: the --with-ipv6 configure option was removed, now IPv6
> support is configured automatically.
> So I don't think that such a change will make any difference.
Perhaps I wasn't clear enough about the use case when proposing this
patch. Its intent is actually to consolidate on the change you
highlighted. I would like to clarify the use case, if you allow me:
Say we wish to disable IPv6 resolution regardless of whether nginx was
built with our without support for it:
resolver 184.108.40.206 220.127.116.11 ipv6=off;
Now the issue is that ipv6=off raises this - cryptic to the neophytes -
error if nginx was built without IPv6 support:
[emerg] host not found in resolver "ipv6=off"
Prior to the change introduced in 1.11.5, one could rely on the
--with-ipv6 option from 'nginx -V' to add the ipv6=off flag or not, and
avoid this error.
However, with this change you referred to, we have no way of
programmatically determine if nginx was built with our without support
for IPv6 (I would love to be proven wrong here, if you happen to be
aware of another way to do so). Hence, this patch's intent is to make
the "ipv6=off" token safe in both modes, and avoid trying to parse it as
a regular address.
With this patch, one can safely assume that IPv6 resolution can *always*
be disabled by simply adding the "ipv6=off" parameter. Additionally, we
also provide a less cryptic error message in case of no support for IPv6
but "ipv6=on" option.
Hence, this patch's primary intent is to consolidate on the referred
change by making the "resolver" directive parsing more robust.
More information about the nginx-devel