php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50953 fsockopen will not work on 'localhost'
Submitted: 2010-02-07 13:31 UTC Modified: 2010-09-07 11:48 UTC
From: tony at marston-home dot demon dot co dot uk Assigned: pajoye (profile)
Status: Closed Package: Sockets related
PHP Version: 5.2.12 OS: Windows XP
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tony at marston-home dot demon dot co dot uk
New email:
PHP Version: OS:

 

 [2010-02-07 13:31 UTC] tony at marston-home dot demon dot co dot uk
Description:
------------
If I use fsockopen with host 'localhost' it fails, but it works with '127.0.0.1' or any other host name.

Reproduce code:
---------------
function connect($host) {
    $faultcode   = null;
    $faultstring = null;
    $conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
    if (!$conn) {
    	echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring ."\n";
    } else {
        echo "Connected to $host OK\n";
    } // if
    return $conn;
} // function

$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');

Expected result:
----------------
I expect to see the message "Connected to <host> OK" for all values of host.

Actual result:
--------------
Warning:  fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Connected to 127.0.0.1 OK
Connected to desktop OK
Connected to www.tonymarston.net OK


Patches

connect_fix_win32 (last revision 2010-09-07 08:26 UTC by cataphract@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-07 16:07 UTC] pajoye@php.net
Did you install IPv6 support for XP?
 [2010-02-07 16:28 UTC] tony at marston-home dot demon dot co dot uk
Yes, but why should this make a difference? I have another Windows XP PC running PHP 5.3.0 and that works OK. I have just upgraded this PC from PHP 4.4.9 to 5.2.12, and it worked OK in PHP 4.

Is it something to do with the fact that IPV6 support is enabled in PHP 5.2.12 but disabled in PHP 5.3.0? Is this a PHP problem and not an OS problem?

FYI my hosts file contains the following:

127.0.0.1       localhost
::1				localhost
127.0.0.1       laptop
192.168.1.64    desktop
 [2010-02-07 17:15 UTC] pajoye@php.net
Comment out the IPv6 entries for localhost (see the other bogus reports for detailed explanations).
 [2010-02-07 17:27 UTC] tony at marston-home dot demon dot co dot uk
I have tried that, but it still doesn't work.
 [2010-02-08 11:39 UTC] aharvey@php.net
Reopening per discussion in bug #50965.
 [2010-02-10 08:17 UTC] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?

Yes.


> Comment out the IPv6 entries for localhost

Of course not! (PHP is not the center of the universe and i need a working IPv6)


> (see the other bogus reports for detailed explanations

Don't you think it's better to fix the bug in the streams code? (Already explained in an other bug report about mysqlnd)


BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4 in the HOSTS file (or just deinstall IPv6) 
- and that's not working for e.g. Windows 7.


Regards,
Carsten
 [2010-02-10 10:18 UTC] pajoye@php.net
Already explained why it can't and won't be fixed in 5.2, neither in 5.3. Use the IP then instead of the hostname. Bogus (duplicated, not really a bug per se but a feature,etc.)
 [2010-02-10 10:57 UTC] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!

If print_r(gethostbynamel('localhost'));  produces the following:

Array
(
    [0] => 127.0.0.1
)

then why can't fsockopen connect to 'localhost'? It is a valid name which is recognised by every other piece of software on my computer, so there is no good reason why fsockopen should have a problem with it.

I have another PC which runs 5.3.0 where fsockopen does not have a problem with 'localhost', therefore there is a bug in 5.2
 [2010-02-10 11:06 UTC] pajoye@php.net
It works just fine here using localhost and ipv4.

You are clearly experiencing the IPv6 problem described in a good dozen bugs here (with solutions).

I'm sorry if it is not acceptable but we can't do anything about that, see the other reports for a complete and detailed explanation.
 [2010-02-10 11:27 UTC] tony at marston-home dot demon dot co dot uk
This has got nothing to do with IPV6 addresses as my hosts file does not contain anf IPV6 addresses. All it has is as follows:

127.0.0.1   localhost

Every other piece of software on my PC uses 'loalhost' without a problem, so should fsockopen in PHP. Curl can manage it, so why not fsockopen.

I have the same setup on another PC which runs Windows XP with IPV6 support and PHP 5.3.0, and it does not have a problem with 'localhost', so this is a genuine bug in 5.2

Do not keep telling me that you have already addressed this issue in other posts because you have not. You nhave suggested removing any IPV6 entries from the hosts file, which I have done, but this does not fix the problem.

If gethostbyname() can work with 'localhost' then why can't fsockopen()?
 [2010-02-12 14:22 UTC] tony at marston-home dot demon dot co dot uk
If IPv6 support is enabled in the operating system it does NOT mean that only IPv6 addresses are allowed, it means that both IPv5 and IPv6 addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating 'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to '127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating 'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?
 [2010-09-07 10:26 UTC] cataphract@php.net
The following patch has been added/updated:

Patch Name: connect_fix_win32
Revision:   1283848007
URL:        http://bugs.php.net/patch-display.php?bug=50953&patch=connect_fix_win32&revision=1283848007
 [2010-09-07 10:27 UTC] cataphract@php.net
-Status: Bogus +Status: Assigned -Assigned To: +Assigned To: pajoye
 [2010-09-07 10:54 UTC] cataphract@php.net
This is indeed a bug.

The problem is that PHP doesn't detect a connection was actively refused and instead times out on it.

The scenario where the address has both ipv4 and ipv6 addresses, the service is only listening on ipv4 and ipv6 has precedence results in:

a) trying ipv6
b) time out
c) fail

instead of

a) trying ipv6
b) connection refused
c) trying ipv4
d) success

I've attached a patch that fixes the issue.
 [2010-09-07 11:47 UTC] pajoye@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303129
Log: - fix bug #50953, socket will not connect to IPv4 address when the host has both ipv4 and ipv6 addresses
 [2010-09-07 11:48 UTC] pajoye@php.net
-Status: Assigned +Status: Closed
 [2010-09-07 11:48 UTC] pajoye@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2010-10-02 20:32 UTC] cataphract@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303958
Log: - Fixed a small mistake in the fix for bug #50953 that made connection timeouts not be detected as such.
 [2012-10-22 15:46 UTC] sp01 at 6vcommerce dot ca
I think this issue still exists in 5.3.x, including the latest 5.3.17.

I had a VPS with Debian 6.0.6 and PHP 5.3.17-1~dotdeb.0 and was unable to connect to smtp.gmail.com via fsockopen until I disabled (sysctl net.ipv6.conf.all.disable_ipv6=1) IPv6 on the VPS.

A strace of the fsockopen call while IPv6 was enabled showed that an attempt to connect via IPv6 was made and timed out, followed by no attempt to connect via IPv4.  Additionally, I had no problem connecting to smtp.gmail.com via openssl s_client so the issue appears isolated to fsockopen.

I've also noticed at least one other claim of this bug in 5.3.x (ref: http://drupal.org/node/805834#comment-6260564)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 06 17:01:27 2024 UTC