php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #54896 Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI
Submitted: 2011-05-21 00:55 UTC Modified: 2011-06-02 18:30 UTC
Votes:6
Avg. Score:4.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: neweracracker at gmail dot com Assigned: cataphract (profile)
Status: Closed Package: Streams related
PHP Version: 5.3SVN-2011-05-20 (snap) OS: Windows 7
Private report: No CVE-ID: None
View Developer Edit
 [2011-05-21 00:55 UTC] neweracracker at gmail dot com 
Description:
------------
I have downloaded a snapshot of php 5.3.7 (Revision: 311276) from windows.php.net/snapshots/ and I am using php.ini-production as my php.ini file

IPv6 is enabled in my machine.

Using Apache and running the test script I got "bool(false)"
Using nginx (with php fastcgi) and running the test script I got "resource(1) of type (stream)"
Running php from the cmd line and running the test script I got "resource(4) of type (stream)"

I think it is supposed to work with all situations.
Please attempt to reproduce and fix this bug.

Thank you.

Test script:
---------------
<?php
var_dump( @fsockopen('localhost',80) );
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-24 18:31 UTC] neweracracker at gmail dot com 
This bug seems to be a consequence of bug #54918
It works flawless prior to this commit svn.php.net/viewvc?view=revision&revision=310691
 [2011-05-31 02:37 UTC] pajoye@php.net
-Status: Open +Status: Critical -Assigned To: +Assigned To: cataphract
 [2011-05-31 02:37 UTC] pajoye@php.net 
Gustavo, pls check this out as well.
 [2011-06-01 13:25 UTC] cataphract@php.net
-Status: Critical +Status: Feedback
 [2011-06-01 13:25 UTC] cataphract@php.net 
Please make sure you are using the Apache binaries from Apache Lounge.

I could reproduce this on a build of Apache that couldn't listen on IPv6 (try adding "Listen [::1]:80" to your httpd.conf and see if Apache starts), but not with Apache Lounge's binaries.
 [2011-06-01 15:51 UTC] neweracracker at gmail dot com
-Status: Feedback +Status: Open
 [2011-06-01 15:51 UTC] neweracracker at gmail dot com 
Then try reproducing with mysql listening in 127.0.0.1:3306

<?php
var_dump( @fsockopen('localhost',3306) );
?>

If it connects then bug is fixed.
 [2011-06-01 15:56 UTC] pajoye@php.net 
@neweracracker at gmail dot com

He said it cannot reproduce it. Do you still see this problem?
 [2011-06-01 16:02 UTC] neweracracker at gmail dot com 
I don't see this problem when apache is listening in ipv6 but I see when only ipv4 is being listened.

Please try my mysql example. If this is fixed. then bug #54832 will be fixed as well since mysqlnd uses streams.
 [2011-06-01 16:03 UTC] pajoye@php.net 
Does your example that both 127.0.0.1 and localhost work when only IPv4 is used?
 [2011-06-01 16:04 UTC] pajoye@php.net 
And please try it.... that's what has been asked. Asking Gustavo to test again is 
good but in the end, we like to know that you don't see the problem anymore.
 [2011-06-01 16:15 UTC] neweracracker at gmail dot com 
127.0.0.1 works
localhost doesn't
 [2011-06-01 16:32 UTC] 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.
 [2011-06-01 17:11 UTC] 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 19:43 UTC] neweracracker at gmail dot com 
Exactly :)

Please review your browser fix since it seems to have caused this.

Thank you.
 [2011-06-01 19:59 UTC] 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-02 10:46 UTC] cataphract@php.net 
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=311730
Log: - Fixed double registering of browscap ini directive. See bug #54896.
 [2011-06-02 10:54 UTC] cataphract@php.net
-Status: Assigned +Status: Feedback
 [2011-06-02 10:54 UTC] cataphract@php.net 
Please test the snapshot for revision 311730, when available.
 [2011-06-02 18:30 UTC] cataphract@php.net
-Status: Feedback +Status: Closed
 [2011-06-02 18:30 UTC] cataphract@php.net 
I'm confident this can be closed now.
 [2011-06-02 19:57 UTC] neweracracker at gmail dot com 
It works :D
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 23:01:28 2024 UTC