Edit report at http://bugs.php.net/bug.php?id=54896&edit=1
ID: 54896
Updated by: cataphr...@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] cataphr...@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] cataphr...@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] cataphr...@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] cataphr...@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
