Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 28489 invoked from network); 10 Dec 2007 21:59:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Dec 2007 21:59:16 -0000 Received: (qmail 3462 invoked by uid 500); 10 Dec 2007 21:59:03 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 3419 invoked by uid 500); 10 Dec 2007 21:59:03 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 3408 invoked by uid 99); 10 Dec 2007 21:59:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2007 13:59:03 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates 66.187.233.31 as permitted sender) Received: from [66.187.233.31] (HELO mx1.redhat.com) (66.187.233.31) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2007 21:59:04 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBALwgWj022900 for ; Mon, 10 Dec 2007 16:58:42 -0500 Received: from turnip.manyfish.co.uk (IDENT:U2FsdGVkX19QPOop8JM5jrWOzEWcwVLSyb/LBEVwcdA@vpn-14-90.rdu.redhat.com [10.11.14.90]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBALwfim008406 for ; Mon, 10 Dec 2007 16:58:41 -0500 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.68) (envelope-from ) id 1J1qe9-0007sK-3o for dev@apr.apache.org; Mon, 10 Dec 2007 21:58:41 +0000 Date: Mon, 10 Dec 2007 21:58:41 +0000 From: Joe Orton To: dev@apr.apache.org Subject: Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c Message-ID: <20071210215841.GA29536@redhat.com> Mail-Followup-To: dev@apr.apache.org References: <20071207184730.046351A9832@eris.apache.org> <20071210090718.GA6065@redhat.com> <475D8C0E.7020800@rowe-clan.net> <20071210195547.GA23734@infiltrator.gizzard.com> <20071210203411.GA28175@redhat.com> <475DAD92.4020204@rowe-clan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <475DAD92.4020204@rowe-clan.net> User-Agent: Mutt/1.5.17 (2007-11-01) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Dec 10, 2007 at 03:20:18PM -0600, William Rowe wrote: > Joe Orton wrote: >> Either way, trying to work around that with an APR resolver hack seems >> completely wrong, -1, it will propagate v4-mapped IPv6 addresses when none >> are necessary, that may very well break/confuse other callers. > > Howso? The user explicitly passes an IPv4 address and requests an IPv6 > flavor sa. No, you've changed the behaviour for *every* family==AF_INET6 lookup whether that's for "www.google.com" or an IPv4 dotted quad. Previously such lookups would fail where the hostname had no v6 address associated; now, where there is a v4 address associated, they will always succeed and give out the v4-mapped IPv6 address. The previous behaviour makes far more sense, and it would not be unreasonable for applications to rely on it. In fact it looks like the APR_IPV6_ADDR_OK flag is exactly a case which relies on that behaviour, and is now presumably broken. joe