The previous bugs reports have been closed WITHOUT a satisfactory explanation. It is not good enough to say "disable IPv6 support in your operating system" as the problem CLEARLY lies within the code for fsockopen.

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?

You are going to have to debug it yourself.  Nobody has been able to 
reproduce your problem and you are the only one who has reported it.  
We can't fix something we can't see.

Rasmus, before you post a comment like that I suggest you first make yourself aware of the facts.
(1) I am not the only one who has reported it, see http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.

This problem exists in Windows XP with IPv6 support enabled, and with PHP 5.2.12 also with IPv6 support enabled.

None of my web browsers (IE, Firefox, Opera, Safari) has a problem with resolving 'localhost' to 127.0.0.1

gethostbyname('localhost') returns '127.0.0.1' without any problem.

The CURL extension can send requests to 'localhost' without a problem.

I have another Windows XP PC with IPv6 support enabled, running PHP 5.3.0 with IPv6 support disabled, and fsockopen() will accept 'localhost' without falling over.

So why can't fsockopen() in 5.2.12 deal with 'localhost', only '127.0.0.1'?

Do NOT tell me that this is a Windows XP issue and that I should disable IPv6 support. IPv4 and IPv6 are designed to run alongside each other and are NOT mutually exclusive. The only function on my PC that has a problem with that is fsockopen(), so stop procrastinating and FIX IT!

-Status: Bogus
+Status: Feedback

Have you tried with 5.2.13RC2 and 5.3.2RC2?

-Status: Feedback
+Status: Open

I have tried 5.2.13RC2, but it produces the same error. I have not tried 5.3.2RC2 as I do not have an error with 5.3.0 (which may be because my copy of 5.3.0 does not have IPv6 support enabled).

I can confirm that the problem is not present in PHP 5.3.0, but _is_ present in PHP 5.3.2... 

It appears the mysql(i) extension is suffering from the same issue: I just spend a couple hours going through various versions of phpMyAdmin (which after upgrading from 5.3.0 simply timed out with a blank page) until discovering this issue. Changing "localhost" into "127.0.0.1" did trick.

Tested using 5.3.2 (VC9 NTS) on Windows Server 2008 (x64). On a side note, both Firefox and MS telnet don't have any issues connecting to localhost over IPv4.

Mysql is not related to this problem, IPv6 is not supported and you have to apply one of the solutions described here or one of the other numerous reports about mysql and IPv6.

Agreed, but that's not my point: 

Just like when using fsockopen() to connect to "localhost", I would expect mysql_connect("localhost") to also attempt to use IPv4, irrespective of whether "localhost" resolves to [::1] or 127.0.0.1.
This is the same behaviour exhibited by Firefox on my system and apparently also the behaviour of several other PHP functions, as made clear in the initial post of this bug.

It does not depend on PHP only but libmysql or mysql server. Please keep posting about the socket issue only here as the myslq&IPv6 questions have been covered numerous times in other reports. The one report per issue rule is also a good way to do not get distracted, thanks for your understanding :)

Fair enough :)

The reproduce code provided fails to connect to "localhost" with fsockopen() in PHP 5.3.2. When using PHP 5.3.0 fsockopen() connects to "localhost" without problems.

I can also confirm that this problem isn't there in PHP 5.3.0. Its there since 
5.3.1.

Unlike PHP 5.3.0, a 64 bit version of PHP 5.3.1 wasn't available at 
http://windows.php.net/qa/, so I tried compiling it myself. After compiling I 
noticed that a script that uses file_get_contents("http://localhost/...") 
wouldn't work until I change the "localhost" to "127.0.0.1". I didn't care about 
it much at that time since it seemed like a small problem. But then I noticed 
that none of the scripts that used mysql were working. I even tried to log in to 
phpMyAdmin and even that didn't work (same problem described by thijsputman). So 
I thought that it was probably a bug with the 64 bit binary and continued using 
PHP 5.3.0. 

But after PHP 5.3.2 was released, I tried compiling it also and noticed that the 
problem was still there. Thinking that it may be related to mysqlnd since the 
version used by PHP 5.3.0 is 5.0.5-dev and the one used by PHP 5.3.2 is 5.0.7-
dev, I tried compiling the mysql, mysqli and pdo mysql extensions with libmysql. 
I has success with the mysql extension only. The mysqli and pdo mysql extension 
failed to compile with libmysql (there were a lot of build errors). Anyway, I 
tried the mysql extension compiled with libmysql and noticed that it was working 
fine! But I needed the mysqli extension to work also and since it failed to 
compile with libmysql, I messed around some more and finally realized that it 
was the same problem as with the file_get_contents. So I tried changing all the 
"localhost" references to "127.0.0.1" and it worked!

Anyway, for whatever reason the mysql extension compiled with libmysql works 
fine with "localhost" but the one compiled with mysqlnd doesn't. So, I hope this 
helps you to find and squish the bug thats causing this. :D

Forgot to mention my operating system. Windows 7 x64.

We recently upgraded to PHP 5.3.2 and can replicate this problem under Windows 7 x64.

Luckily the workaround of using '127.0.0.1' in the fsockopen address instead of 'localhost' is relatively easy but it broke a large volume of our existing code. Very annoying.

Please fix this asap.

I can confirm this on Vista x86 with the precompiled 5.3.2 VC6 ts

One small note, if this is of any help.  First, I am new to PHP, and ran into this same issue with PHPMyAdmin and Drupal.  I am on Windows 7 x64, and found some info on another site.  However, In my case, I was having an issue with Drupal trying to check http://family-hp/ (my computer name).  At the time, my hosts file (c:\windows\system32\etc\hosts) contained:

127.0.0.1       localhost
::1             localhost

When I ran the script, I received:

called connect('family-hp')
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. 
called connect('localhost')
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. 
called connect('127.0.0.1')
Connected to 127.0.0.1 OK 
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK 

(note: I added a piece of code to indicate how 'connect' was called.)

I made the following changes to hosts:

1. Added a line for family-hp (not sure why I need this, since IE has no problem resolving my computer name!).
2. Based on information I found on another site, I commented out the IPv6 loopback.

New hosts file:

127.0.0.1       family-hp
127.0.0.1       localhost
#::1            localhost

Rerun of script:

called connect('family-hp')
Connected to family-hp OK 
called connect('localhost')
Connected to localhost OK 
called connect('127.0.0.1')
Connected to 127.0.0.1 OK 
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK 

So, if you give hosts a single choice of IPv4 loopback, and no IPv6 loopback, it works!

Mike

Oops I hadn't noticed this bug existed and modified #50953 instead. Sorry.

Fix and discussions will go now into the bug #50963.

Fix and discussions will go now into the bug #50953.

I have been having this problem for a long time, the past 9mos or so. My problem 
showed up in Drupal, which uses the fuction to make calls for system updates or 
feeds. I hunted for months for a solution, and found nothing in the Drupal 
forums that worked for me. I finally decided to sit down and roll up my sleeves 
and dig down into the PHP code and found the posts that discuss this 10060 
error. I did some debugging and voila- the Drupal system's error is occuring 
because PHP is reporting back the 10060 error. I will post details later, but 
I'm posting this right now to let you know. Even though I don't share his 
temperament, I feel for him. There are tons of folks in the Drupal forums 
reporting this problem, and none of the postings there even touched on this 
10060 error, as far as I can see. Sometimes one person will find a fix to the 
Drupal error by changing a PHP variable- others fix it another way- others still 
another. None of the fixes worked for me, and now I'm finding that PHP (which 
DOES have IPv6 enabled in php_info) is reporting the 10060 error. So I'm going 
to spend the next week doing as much debugging as I can to see if I can figure 
out what's going on.

I just wanted to let others like me know that they're not crazy, they're not 
alone, and to try and be patient and have hope. IPv6 is new and it will 
obviously take some time before it is integrated fully and made more stable in 
our systems.

@victorcharlesiii at yahoo dot com

Hope does not help a lot, but reading the comment here and in the actual issue where this problem is discussed would have told you that 5.3.4 will have the fix for this problem (http://bugs.php.net/50953).