file_get_contents - failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

Question

I'm having some weird problems with file_get_contents after moving my site to a new domain. I had to set up a new domain and IP address (using Plesk) to get a new ssl certificate working. Now my file_get_contents calling a script on the same domain is giving me this:

failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

If I call the same url using file_get_contents on another server it works fine, and if I call www.google.com from the server thats failing that works, so it only seems to be if I call a url on the same sever!

I have a feeling it might have something to do with having two IPs with two different ssl certificates on the one server, when i file_get_contents / (index page) of the server from the server I get the plesk 'this is a new domain' page so its like apache isnt looking up the right virtual host when its called from its own sever.

To clarify (hopefully!):

On the server hosting the domain:

file_get_contents('https://mydomain.com?limit=4&offset=0&s_date=2012-02-05&e_date=2012-03-13&order=release_date&dir=desc&cid=12');

gives "failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found"

file_get_contents('http://www.google.com');

works correctly

On another server:

file_get_contents('https://mydomain.com?limit=4&offset=0&s_date=2012-02-05&e_date=2012-03-13&order=release_date&dir=desc&cid=12');

works fine.

I have tried turning ssl off and I still get the same problem.

Answer 1

If you just need to handle the warning when the URL is not found (as I did), you may just do this to turn Warnings into Exceptions:

set_error_handler(
  function ($err_severity, $err_msg, $err_file, $err_line, array $err_context) {
    // do not throw an exception if the @-operator is used (suppress)
    if (error_reporting() === 0) return false;

    throw new ErrorException( $err_msg, 0, $err_severity, $err_file, $err_line );
  },
  E_WARNING
);
try {
  $contents = file_get_contents($your_url);
} catch (Exception $e) {
  echo $e->getMessage();
}
restore_error_handler();

Solution based on this thread/question.

Answer 2

I've had this problem too, when I working on a little test server at home. The domain name is resolved to your external IP address, and a request is sent. But because the request is coming from inside your network, the router doesn't recognise it as a normal request. It probably has a web interface for configuring it, and tries to return a page from its own management system, which is then not found at the path you specified.

In that case, I was working on a Windows PC, and I could solve it by adding the domain I was testing to my hosts file, specifying 127.0.0.1 as the IP-address (or the IP-address of the server, if it is another machine within the same network). In Linux there should be a similar solution, I think.

The problem isn't PHP or your server, but your router.

Answer 3

Most hosting provides now block the furl_open parameter which allows you to use file_get_contents() to load data from an external url.

You can use CURL or a PHP client library like Guzzle

Answer 4

Try to do this :

file_get_contents('https://mydomain.com?'.urlencode('limit=4&offset=0&s_date=2012-02-05&e_date=2012-03-13&order=release_date&dir=desc&cid=12'));

Answer 5

I got the same error in CodeIgniter 3. I was doing like this
file_get_contents(base_url('database.json'));
and then this
file_get_contents(site_url('database.json'));

My problem get resolved after I changed it to this
file_get_contents(__DIR__.'/database.php');
Reason behind this was, I was trying to get the internal resource from external url which these methods base_url and site_url return. While __DIR__ return internal url.

Answer 6

For Laravel Dusk/GitHub Actions

For anyone running into this issue on Laravel Dusk for Chrome/Chromium versions after 114, this is likely caused by Google changing the upstream URLs.

This seems to have been fixed in this Dusk issue here, so theoretically all that's needed to fix this properly is a composer require laravel/dusk --with-all-dependencies, but at least in my case, this would update a lot of dependencies and seems highly likely to break my application. I've asked on that issue what the best course of action is for a legacy Laravel application (Laravel 8 in my case), but in the meantime downgrading both the Chrome/Chromium browser and the Chrome driver to v114 should be a good enough workaround.

This is easier said than done and it's taken me over a day to figure out how to do it successfully on GitHub Actions, but adding the following step to your workflow file should be all you need to get your builds running again:

  - name: Downgrade Chrome browser to v114
    uses: browser-actions/setup-chrome@v1
    with:
      chrome-version: 1134343 # Last commit number for Chrome v114
    id: setup-chrome
  - run: sudo ln -fs ${{ steps.setup-chrome.outputs.chrome-path }} /usr/bin/google-chrome
  - name: Downgrade Chrome driver to v114
    run: php artisan dusk:chrome-driver `/usr/bin/google-chrome --version | cut -d " " -f3 | cut -d "." -f1`