<div dir="ltr">Hello,<div><br></div><div style>Yesterday you had a talk on Highload++ and said about lack of IPv6 resolver support. Do you have any news about my patch?</div><div style><br></div><div style>Regards,</div><div style>
Anton Kortunov.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 5:02 PM, Maxim Konovalov <span dir="ltr"><<a href="mailto:maxim@nginx.com" target="_blank">maxim@nginx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Anton,<br>
<br>
First of all, thanks for the patches!<br>
<br>
Just want to let you know that we have a ticket in our internal<br>
system assigned your patches to the developer for review but it'll<br>
take some time due to other tasks and complexity of the patch series.<br>
<div class="im"><br>
On 7/10/13 9:17 PM, ToSHiC wrote:<br>
> Hello,<br>
><br>
> I've split this big patch into several small patches, taking into<br>
> account your comments. I'll send each part in separate email. Here<br>
> is the first one.<br>
><br>
> commit 597d09e7ae9247c5466b18aa2ef3f5892e61b708<br>
> Author: Anton Kortunov <<a href="mailto:toshic.toshic@gmail.com">toshic.toshic@gmail.com</a><br>
</div>> <mailto:<a href="mailto:toshic.toshic@gmail.com">toshic.toshic@gmail.com</a>>><br>
<div class="im">> Date: Wed Jul 10 13:14:52 2013 +0400<br>
><br>
> Added new structure ngx_ipaddr_t<br>
><br>
> This structure contains family field<br>
> and the union of ipv4/ipv6 structures in_addr_t and in6_addr.<br>
><br>
> diff --git a/src/core/ngx_inet.h b/src/core/ngx_inet.h<br>
> index 6a5a368..077ed34 100644<br>
> --- a/src/core/ngx_inet.h<br>
> +++ b/src/core/ngx_inet.h<br>
> @@ -68,6 +68,16 @@ typedef struct {<br>
><br>
><br>
> typedef struct {<br>
> + ngx_uint_t family;<br>
> + union {<br>
> + in_addr_t v4;<br>
> +#if (NGX_HAVE_INET6)<br>
> + struct in6_addr v6;<br>
> +#endif<br>
> + } u;<br>
> +} ngx_ipaddr_t;<br>
> +<br>
> +typedef struct {<br>
> struct sockaddr *sockaddr;<br>
> socklen_t socklen;<br>
> ngx_str_t name;<br>
><br>
><br>
><br>
> On Mon, Jun 17, 2013 at 7:30 PM, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>> wrote:<br>
><br>
> Hello!<br>
><br>
> On Fri, Jun 14, 2013 at 09:44:46PM +0400, ToSHiC wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > We needed this feature in our company, I found that it is in<br>
> milestones of<br>
> > version 1.5 but doesn't exist yet. So I've implemented it<br>
> based in 1.3 code<br>
> > and merged in current 1.5 code. When I wrote this code I<br>
> mostly cared about<br>
> > minimum intrusion into other parts of nginx.<br>
> ><br>
> > IPv6 fallback logic is not a straightforward implementation of<br>
> suggested by<br>
> > RFC. RFC states that IPv6 resolving have priority over IPv4,<br>
> and it's not<br>
> > very good for Internet we have currently. With this patch you<br>
> can specify<br>
> > priority, and in upstream and mail modules I've set IPv4 as<br>
> preferred<br>
> > address family.<br>
> ><br>
> > Patch is pretty big and I hope it'll not break mailing list or<br>
> mail clients.<br>
><br>
> You may want to try to split the patch into smaller patches to<br>
> simplify review. See also some hints here:<br>
><br>
> <a href="http://nginx.org/en/docs/contributing_changes.html" target="_blank">http://nginx.org/en/docs/contributing_changes.html</a><br>
><br>
> Some quick comments below.<br>
><br>
> [...]<br>
><br>
> > - addr = ntohl(ctx->addr);<br>
> > +failed:<br>
> > +<br>
> > + //addr = ntohl(ctx->addr);<br>
> > + inet_ntop(ctx->addr.family, &ctx->addr.u, text,<br>
> > NGX_SOCKADDR_STRLEN);<br>
> ><br>
> > ngx_log_error(NGX_LOG_ALERT, r->log, 0,<br>
> > - "could not cancel %ud.%ud.%ud.%ud<br>
> resolving",<br>
> > - (addr >> 24) & 0xff, (addr >> 16) & 0xff,<br>
> > - (addr >> 8) & 0xff, addr & 0xff);<br>
> > + "could not cancel %s resolving", text);<br>
><br>
> 1. Don't use inet_ntop(), there is ngx_sock_ntop() instead.<br>
><br>
> 2. Don't use C++ style ("//") comments.<br>
><br>
> 3. If some data is only needed for debug logging, keep relevant<br>
> calculations under #if (NGX_DEBUG).<br>
><br>
> [...]<br>
><br>
> > @@ -334,6 +362,7 @@<br>
> > ngx_http_upstream_create_round_robin_peer(ngx_http_request_t *r,<br>
> > peers->peer[i].current_weight = 0;<br>
> > peers->peer[i].max_fails = 1;<br>
> > peers->peer[i].fail_timeout = 10;<br>
> > +<br>
> > }<br>
> > }<br>
> ><br>
><br>
> Please avoid unrelated changes.<br>
><br>
> [...]<br>
><br>
> --<br>
> Maxim Dounin<br>
> <a href="http://nginx.org/en/donation.html" target="_blank">http://nginx.org/en/donation.html</a><br>
><br>
> _______________________________________________<br>
> nginx-devel mailing list<br>
</div></div>> <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a> <mailto:<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
> _______________________________________________<br>
> nginx-devel mailing list<br>
> <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Maxim Konovalov<br>
+7 (910) 4293178<br>
<a href="http://nginx.com/services.html" target="_blank">http://nginx.com/services.html</a><br>
</font></span></blockquote></div><br></div>