Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: stasismedia at gmail dot com
Reported by: ramsey@php.net
Summary: file_get_contents() no longer returns false on 4xx
responses
Status: Open
Type: Bug
Package: Filesystem function related
Operating System: CentOS 6.2
PHP Version: 5.4.0
Block user comment: N
Private report: N
New Comment:
FYI, I experienced this issue when PHP was compiled with --with-curlwrappers
Previous Comments:
------------------------------------------------------------------------
[2013-03-04 15:04:51] php at maisqi dot com
Just noted that I gave a wrong URI to the script; sorry, here is the right one:
http://maisqi.com/outros/bugs/php/61336
------------------------------------------------------------------------
[2013-03-04 15:01:49] php at maisqi dot com
vestigalorgan, you are right: it should return false in all three cases. Thanks for correcting.
------------------------------------------------------------------------
[2013-03-02 01:50:21] vestigalorgan at gmail dot com
I've run the test case that maisqi provided, and here are my results:
1. Using file_file_get_contents() on an non-existing resource on a existing domain:
The result: boolean
$http_response_header: array
2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the
context:
The result: boolean
$http_response_header: NULL
3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on
the context:
The result: boolean
$http_response_header: NULL
This is on Ubuntu 12.04 LTS 64-bit with Apache 2.2.22 and PHP 5.3.10-1ubuntu3.5 with the
Suhosin-Patch. Everything appears to be working fine there.
Shouldn't the output of the results be a boolean false, not NULL, maisqi?
------------------------------------------------------------------------
[2013-03-01 09:54:17] php at maisqi dot com
I think I have new info on this issue. If you check the URI at the bottom you'll find three
tests:
1. Using file_file_get_contents() on an non-existing resource on a existing domain:
Result : empty string
$http_response_header : an array
2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the
context:
Result : empty string
$http_response_header : NULL
3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on
the context:
Result : non empty string
$http_response_header : an array
I'd expect that all the results should be NULL.
I think the problem has to to with idiosyncratic behavior on some internal library. In the third
test we can see that there's something asking OpenDNS when trying to deal with the non-existing
behavior; and then it sends a Location header. This behavior is not documented.
- The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected;
- On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected;
- On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it works as expected;
- On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected.
So I'd say it has to do with the underlying system libraries and configuration; it would be
nice if others test the script on other kind of servers...
Test script: http://maisqi/outros/bugs/php/61336
[CentOS / PHP 5.4.11]
------------------------------------------------------------------------
[2013-01-14 23:52:39] vestigalorgan at gmail dot com
I'm experiencing a similar issue in the PHP version 5.4.7 that ships with XAMPP. When I open a
web URL that throws a warning such as "Warning:
file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream: No connection could
be made because the target machine actively refused it.", file_get_contents() returns an empty
string, instead of false.
I'm not sure if this is related to this bug or I should file a new one. I'm experiencing
this on Windows 7 Professional, SP1 32-bit. I'm only using the first parameter of
file_get_contents().
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=61336--
Edit this bug report at https://bugs.php.net/bug.php?id=61336&edit=1