Bug #54896 [Asn->Fbk]: Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI

Edit report at http://bugs.php.net/bug.php?id=54896&edit=1 ID: 54896 Updated by: cataphract@php.net Reported by: neweracracker at gmail dot com Summary: Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI -Status: Assigned +Status: Feedback Type: Bug Package: Streams related Operating System: Windows 7 PHP Version: 5.3SVN-2011-05-20 (snap) Assigned To: cataphract Block user comment: N Private report: N New Comment: Please test the snapshot for revision 311730, when available. Previous Comments: ------------------------------------------------------------------------ [2011-06-02 10:46:42] cataphract@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=311730 Log: - Fixed double registering of browscap ini directive. See bug #54896. ------------------------------------------------------------------------ [2011-06-01 19:59:07] cataphract@php.net Possibly the merge to 5.3 has butchered something. This is caused by the timeout being too low because the ini entry default_socket_timeout is not registered (doesn't appear in phpinfo()). If you pass fsockopen a timeout of, say, 10s, it works correctly. I'll take a closer look later today. ------------------------------------------------------------------------ [2011-06-01 19:43:40] neweracracker at gmail dot com Exactly :) Please review your browser fix since it seems to have caused this. Thank you. ------------------------------------------------------------------------ [2011-06-01 17:11:17] cataphract@php.net Sorry. I was trying with trunk, not 5.3. I can now reproduce this on 5.3 (but not trunk) on the Apache SAPI (but not with FastCGI). ------------------------------------------------------------------------ [2011-06-01 16:32:23] cataphract@php.net Works here: Script: var_dump(fsockopen("localhost", 9876)); ncat -4 -k -l 9876 -v -v 15:22:42,3106124 httpd.exe 2504 TCP Reconnect 0:0:0:0:0:0:0:1:6660 -> 0:0:0:0:0:0:0:1:9876 SUCCESS Length: 0, seqnum: 0, connid: 0 15:22:42,8106355 httpd.exe 2504 TCP Reconnect 0:0:0:0:0:0:0:1:6660 -> 0:0:0:0:0:0:0:1:9876 SUCCESS Length: 0, seqnum: 0, connid: 0 15:22:42,8210523 httpd.exe 2504 TCP Connect 127.0.0.1:6661 -> 127.0.0.1:9876 SUCCESS Length: 0, mss: 1460, sackopt: 1, tsopt: 0, wsopt: 1, rcvwin: 8192, rcvwinscale: 8, sndwinscale: 8, seqnum: 0, connid: 0 15:22:42,8216731 httpd.exe 2504 TCP Disconnect 127.0.0.1:6661 -> 127.0.0.1:9876 SUCCESS Length: 0, seqnum: 0, connid: 0 So tries IPv6, fails, then tries IPv4. Now with a process listening on IPv6: ncat -6 -k -l 9876 -v -v 15:25:44,6140323 httpd.exe 2504 TCP Accept 0:0:0:0:0:0:0:1:6672 -> 0:0:0:0:0:0:0:1:9876 SUCCESS Length: 0, mss: 1440, sackopt: 1, tsopt: 0, wsopt: 1, rcvwin: 8192, rcvwinscale: 8, sndwinscale: 8, seqnum: 0, connid: 0 15:25:44,6238583 httpd.exe 2504 TCP Disconnect 0:0:0:0:0:0:0:1:6672 -> 0:0:0:0:0:0:0:1:9876 SUCCESS Length: 0, seqnum: 0, connid: 0 Tries with IPv6 and works the first time. As expected. The only normal case when "127.0.0.1" would work but not localhost with a service listening only with IPv4 is if the packet for the initial attempt with IPv6 would get dropped instead of the OS getting a RST packet back rejecting the connection. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54896 -- Edit this bug report at http://bugs.php.net/bug.php?id=54896&edit=1