CODEWITHSUNDEEP
phpfopen
Your Common Sense
Your Common Sense

Reputation: 157862

file_get_contents returns empty string

I am hesitated to ask this question because it looks weird. But anyway. Just in case someone had encountered the same problem already... filesystem functions (fopem, file, file_get_contents) behave very strange for http:// wrapper

This error seems inapplicable because in my case it doesn't work for every url or host.

php-fpm 5.2.11 Linux version 2.6.35.6-48.fc14.i686 ([email protected])

Upvotes: 24

Views: 70068

Answers (8)

Francisco Campos
Francisco Campos

Reputation: 1209

My problem was solved dealing with the SSL:

$arrContextOptions = array(
  "ssl" => array(
    "verify_peer" => false,
    "verify_peer_name" => false,
  ),
);  

$context = stream_context_create($arrContextOptions);
        
$jsonContent = file_get_contents("https://www.yoursite.com", false, $context);

Upvotes: 2

Donatas Olsevičius
Donatas Olsevičius

Reputation: 1350

Is http stream registered in your PHP installation? Look for "Registered PHP Streams" in your phpinfo() output. Mine says "https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip".

If there is no http, set allow_url_fopen to on in your php.ini.

Upvotes: 2

Jeremy
Jeremy

Reputation: 2669

When you use the http stream wrapper PHP creates an array for you called $http_response_header after file_get_contents() (or any of the other f family of functions) is called. This contains useful info on the state of the response. Could you do a var_dump() of this array and see if it gives you any more info on the response?

It's a really weird error that you're getting. The only thing I can think of is that something else on the server is blocking the http requests from PHP, but then I can't see why cURL would still be ok...

Upvotes: 5

Master Drools
Master Drools

Reputation: 738

I had the same issue in Windows after installing XAMPP 1.7.7. Eventually I managed to solve it by adding the following line to php.ini (while having allow_url_fopen = On):

extension=php_openssl.dll

Upvotes: -1

Eric Caron
Eric Caron

Reputation: 6273

I fixed this issue on my server (running PHP 5.3.3 on Fedora 14) by removing the --with-curlwrapper from the PHP configuration and rebuilding it.

Upvotes: 23

mario
mario

Reputation: 145482

Sounds like a bug. But just for posterity, here are a few things you might want to debug.

  • allow_url_fopen: already tested
  • PHP under Apache might behave differently than PHP-CLI, and would hint at chroot/selinux/fastcgi/etc. security restrictions
  • local firewall: unlikely since curl works
  • user-agent blocking: this is quite common actually, websites block crawlers and unknown clients
  • transparent proxy from your ISP, which either mangles or blocks (PHP user-agent or non-user-agent could be interpreted as malware)
  • PHP stream wrapper problems

Anyway, first let's proof that PHPs stream handlers are functional:

<?php
     if (!file_get_contents("data:,ok")) {
          die("Houston, we have a stream wrapper problem.");
     }

Then try to see if PHP makes real HTTP requests at all. First open netcat on the console:

nc -l 80000

And debug with just:

<?php
    print file_get_contents("http://localhost:8000/hello");

And from here you can try to communicate with PHP, see if anything returns if you variate the response. Enter an invalid response first into netcat. If there's no error thrown, your PHP package is borked.

(You might also try communicating over a "tcp://.." handle then.)

Next up is experimenting with http stream wrapper parameters. Use http://example.com/ literally, which is known to work and never block user-agents.

$context = stream_context_create(array("http"=>array(
    "method" => "GET",
    "header" => "Accept: xml/*, text/*, */*\r\n",
    "ignore_errors" => false,
    "timeout" => 50,
));

print file_get_contents("http://www.example.com/", false, $context, 0, 1000);

I think ignore_errors is very relevant here. But check out http://www.php.net/manual/en/context.http.php and specifically try to set protocol_version to 1.1 (will get chunked and misinterpreted response, but at least we'll see if anything returns).

If even this remains unsuccessful, then try to hack the http wrapper. 

<?php
    ini_set("user_agent" , "Mozilla/3.0\r\nAccept: */*\r\nX-Padding: Foo");

This will not only set the User-Agent, but inject extra headers. If there is a processing issue with construction the request within the http stream wrapper, then this could very eventually catch it.

Otherwise try to disable any Zend extensions, Suhosin, PHP xdebug, APC and other core modules. There could be interferences. Else this is potentiallyan issue specific to the Fedora package. Try a new version, see if it persists on your system.

Upvotes: 19

c0rnh0li0
c0rnh0li0

Reputation: 149

What does a test with fsockopen tell you?

Is the test isolated from other code?

Upvotes: -1

powtac
powtac

Reputation: 41050

Use http://pear.php.net/reference/PHP_Compat-latest/__filesource/fsource_PHP_Compat__PHP_Compat-1.6.0a2CompatFunctionfile_get_contents.php.html and rename it and test if the error occurs with this rewritten function.

Upvotes: -3

Related Questions