On Wed, Apr 13, 2011 at 1:51 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On 4/13/2011 9:53 AM, Jeff Trawick wrote: >> On Tue, Apr 5, 2011 at 9:28 AM, <traw...@apache.org> wrote: >>> Author: trawick >>> Date: Tue Apr 5 13:28:59 2011 >>> New Revision: 1089031 >>> >>> URL: http://svn.apache.org/viewvc?rev=1089031&view=rev >>> 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? (That one broke IP addresses on win2k, see > for example https://issues.apache.org/bugzilla/show_bug.cgi?id=41693 ).
That one is hard to follow... It points to another bug, that one said 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 connections? > 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(): (*new)->remote_addr_unknown = 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.
