Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: php at maisqi dot com
Reported by: ram...@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:
Just noted that I gave a wrong URI to the script; sorry, here is the right one:
http://maisqi.com/outros/bugs/php/61336
Previous Comments:
------------------------------------------------------------------------
[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().
------------------------------------------------------------------------
[2012-10-18 15:51:46] stasismedia at gmail dot com
I should add...
Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox.
------------------------------------------------------------------------
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
