IPv6 support in resolver
Maxim Dounin
mdounin at mdounin.ru
Mon Jun 17 15:30:21 UTC 2013
Hello!
On Fri, Jun 14, 2013 at 09:44:46PM +0400, ToSHiC wrote:
> Hello,
>
> We needed this feature in our company, I found that it is in milestones of
> version 1.5 but doesn't exist yet. So I've implemented it based in 1.3 code
> and merged in current 1.5 code. When I wrote this code I mostly cared about
> minimum intrusion into other parts of nginx.
>
> IPv6 fallback logic is not a straightforward implementation of suggested by
> RFC. RFC states that IPv6 resolving have priority over IPv4, and it's not
> very good for Internet we have currently. With this patch you can specify
> priority, and in upstream and mail modules I've set IPv4 as preferred
> address family.
>
> Patch is pretty big and I hope it'll not break mailing list or mail clients.
You may want to try to split the patch into smaller patches to
simplify review. See also some hints here:
http://nginx.org/en/docs/contributing_changes.html
Some quick comments below.
[...]
> - addr = ntohl(ctx->addr);
> +failed:
> +
> + //addr = ntohl(ctx->addr);
> + inet_ntop(ctx->addr.family, &ctx->addr.u, text,
> NGX_SOCKADDR_STRLEN);
>
> ngx_log_error(NGX_LOG_ALERT, r->log, 0,
> - "could not cancel %ud.%ud.%ud.%ud resolving",
> - (addr >> 24) & 0xff, (addr >> 16) & 0xff,
> - (addr >> 8) & 0xff, addr & 0xff);
> + "could not cancel %s resolving", text);
1. Don't use inet_ntop(), there is ngx_sock_ntop() instead.
2. Don't use C++ style ("//") comments.
3. If some data is only needed for debug logging, keep relevant
calculations under #if (NGX_DEBUG).
[...]
> @@ -334,6 +362,7 @@
> ngx_http_upstream_create_round_robin_peer(ngx_http_request_t *r,
> peers->peer[i].current_weight = 0;
> peers->peer[i].max_fails = 1;
> peers->peer[i].fail_timeout = 10;
> +
> }
> }
>
Please avoid unrelated changes.
[...]
--
Maxim Dounin
http://nginx.org/en/donation.html
More information about the nginx-devel
mailing list