Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.214.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Q+Hq4bCVFx3Id/5vMioWh0s7Krhvdh58dz1UZBTr7n1AjOTKLcFqlvbfWN7GmVSmja
         hO2CmMovSk3LgqI3qLfBDx6ackyk7Fk5KZ8aE7nvpMvI2zSMTqZ7Gwv8pD7fBfUPwezT
         DLIHcf71f3macaKfBlkfe80Jh6MJOLF/KrphQ=
MIME-Version: 1.0
In-Reply-To: <BANLkTik1SCPgiBzx-xHPHHSqR3po64mz_Q@mail.gmail.com>
References: <20110405132859.65E982388901@eris.apache.org>
	<BANLkTikS6QWfuLG6Yk2VHoLYBN5sr9a0OA@mail.gmail.com>
	<4DA5E287.8030608@rowe-clan.net>
	<BANLkTi=Jqmh_v57iDYa+tcfQzjxSyg1Fmw@mail.gmail.com>
	<4DA5EB35.6050406@rowe-clan.net>
	<BANLkTik1SCPgiBzx-xHPHHSqR3po64mz_Q@mail.gmail.com>
Date: Wed, 13 Apr 2011 15:49:11 -0400
Message-ID: <BANLkTimV6x5F2zpkH6QzQ43KC3OUvG75cw@mail.gmail.com>
Subject: Re: svn commit: r1089031 - in /apr/apr/trunk: CHANGES
 network_io/win32/sockets.c
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 13, 2011 at 2:53 PM, Jeff Trawick <trawick@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 2:28 PM, William A. Rowe Jr.
> <wrowe@rowe-clan.net> wrote:
>> On 4/13/2011 1:11 PM, Jeff Trawick wrote:
>>> On Wed, Apr 13, 2011 at 1:51 PM, William A. Rowe Jr.
>>> <wrowe@rowe-clan.net> wrote:
>>>> On 4/13/2011 9:53 AM, Jeff Trawick wrote:
>>>>> On Tue, Apr 5, 2011 at 9:28 AM, =A0<trawick@apache.org> wrote:
>>>>>> Author: trawick
>>>>>> Date: Tue Apr =A05 13:28:59 2011
>>>>>> New Revision: 1089031
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=3D1089031&view=3Drev
>>>>>> Log:
>>>>>> restructure Windows apr_socket_connect() to more closely match
>>>>>> the Unix implementation, fixing the getpeername() optimization
>>>>>> and WSAEISCONN behavior
>>>>>>
>>>>>> PR: 48736 (covered WSAISCONN issue)
>>>>>> Submitted by: <inoue ariel-networks.com> (WSAISCONN handling)
>>>>>> Reworked/extended by: trawick
>>>>>
>>>>> trivia: getpeername() fails for a connected IPv6 socket on XP; this
>>>>> change to get the getpeername() optimization to work "fixes" that for
>>>>> the common case
>>>>
>>>> Is this another aspect of the same flaw we just worked through, when I=
 last
>>>> attempted to normalize this? =A0(That one broke IP addresses on win2k,=
 see
>>>> for example https://issues.apache.org/bugzilla/show_bug.cgi?id=3D41693=
 ).
>>>
>>> That one is hard to follow... =A0It points to another bug, that one sai=
d
>>> Win32DisableAcceptEX was a work-around, and there's a later update
>>> from you saying "solved after 2.2.4 for windows 2000".
>>>
>>> I'll look a little further for earlier bug fixes.
>>>
>>>>> I'll probably backport this to 1.4.x for other reasons (but after 1.4=
.3).
>>>>
>>>> So if we tag httpd-2.3-something against 1.4.3, with IPv6 enabled, we =
will
>>>> start collecting similar reports to the one above, for XP IPv6 connect=
ions?
>>>>
>>>
>>> In testing 1.4.latest on XP this a.m. I didn't see an issue with my
>>> simple server app which retrieved local and remote addresses, as the
>>> getpeername() optimization on that side of the connection is working.
>>>
>>> apr_socket_accept() has this line to let it use the info from accept()
>>> instead of calling getpeername(): =A0 =A0 (*new)->remote_addr_unknown =
=3D 0;
>>>
>>> With 1.4.latest, the getpeername() optimization on the client side is
>>> not working, and getpeername() on IPv6 is where the XP bug is.
>>
>> What I'm suggesting is that AcceptEx fundamentally alters the way that
>> getpeername() et al will access the socket, sometimes to their detriment=
.
>>
>> Make sure you are testing both with and without using AcceptEx.

Using the latest httpd 2.2.x and apr 1.4.x on Windows 7, along with a
little debugging technique I like to call "printf", I can confirm that
neither getsockname() nor getpeername() are called by APR for
retrieving info about the connected socket, whether or not
Win32DisableAcceptEx is present, whether or not IPv6 sockets are used.
 Client addresses in the access and error log are formatted as
expected.

Avoiding getpeername() on this socket bypasses the IPv6-specific issue
on XP and the general issue on Win2K.

It would be cool to see it run there, but the code isn't going to
behave any differently w.r.t. getsockname()/getpeername().