Bug 41321 - apr_socket_addr_get() fails - getpeername invalid after AcceptEx
apr_socket_addr_get() fails - getpeername invalid after AcceptEx
Product: APR
Classification: Unclassified
Component: APR
Other Windows 2000
: P2 normal (vote)
: ---
Assigned To: Apache Portable Runtime bugs mailinglist
Depends on:
  Show dependency tree
Reported: 2007-01-08 15:39 UTC by Tom Donovan
Modified: 2007-01-09 11:22 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Donovan 2007-01-08 15:39:29 UTC
Change 480213 (& 480212) to network_io/win32/sockets.c
now causes apr_socket_addr_get() in network_io/unix/sockaddr.c 
to call get_remote_addr() because remote_addr_unknown is set.

get_remote_addr() calls the Windows function getpeername().

This step is unnecessary on Windows - the remote IP is already present.

getpeername() does not work correctly on Windows 2000, it always returns It works correctly on XP and Win2003. Windows bug?

getpeername() doc is at http://msdn2.microsoft.com/en-us/library/ms738533.aspx
Comment 1 William A. Rowe Jr. 2007-01-09 11:22:20 UTC
Fixed remote_host_unknown in APR trunk/1.2 branch for apr_socket_make.

Following AcceptEx, apr_socket_make must be passed the collected remote socket
on such platforms as it inhibits the proper behavior of getpeername in some

Workaround is to avoid AcceptEx altogether on affected systems.