file_get_contents() works differently on different machines

Question

I have written a piece of php code to use file_get_contents() to download a .js file from a site and try to run the code from 2 different machines and they produce different results. The code is:

$link = "https://www.scotchwhiskyauctions.com/scripting/store-scripting_frontend.js";

$options = array(
  'http'=>array(
     'method'=>"GET",
     'header'=>"Accept-language: en\r\n" .
          "User-Agent: Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.102011-10-16 20:23:10\r\n"  ),
  'ssl'=>array(
     'verify_peer'=>false,
     'verify_peer_name'=>false),
);
$context = stream_context_create($options);
$line = file_get_contents($link, false, $context);
var_dump($http_response_header);
echo $line;
exit;

When I run this piece of code in a Debian 8.11 machine it produces the following error:

PHP Warning:  file_get_contents(https://www.scotchwhiskyauctions.com/scripting/store-scripting_frontend.js): failed to open stream: Connection timed out in /var/www/test.php on line 4
PHP Notice:  Undefined variable: http_response_header in /var/www/test.php on line 4
NULL

However when I ran the exact same code on a different machine (Debian 4.16.12-1kali1) it can obtain the file content and the variable $http_response_header contains all the response header. Both machines use php7.2. After spending days trying to figure out what causes the Debian 8.11 machine to not be able to read the file, I used wget on both machines, and noticed that again, the Debian 8.11 (jessie) machine failed to read the file.

I suspected it has something to do with the ssl certificates so I ran

sudo update-ca-certificates
sudo update-ca-certificates --fresh

but it does not help at all.

Can anyone please point me to some direction?

@Dormilich `$http_response_header` is automatically filled - you don't have to define it: http://php.net/manual/de/reserved.variables.httpresponseheader.php — Philipp, Jul 03 '18 at 09:17
`allow_url_fopen` is set to On in the `php.ini` file of both machines, just FYI. — albertma789, Jul 03 '18 at 09:18
@albertma789 Can you access the URL at all? (Using a browser f.e.) — Xatenev, Jul 03 '18 at 09:20
Could be an IPV4/6 problem - you could try to bind the strem context to ipv4 with: `'socket' => ['bindto' => '0:0']` — Philipp, Jul 03 '18 at 09:22
@albertma789 `tcpdump -nni any host 111.111.111.111 and port 80` where `111.111.111.111` is the IP of whatever you are trying to reach. Then execute your script again and paste the output. To make sure the HTTP Request arrives at your server properly. — Xatenev, Jul 03 '18 at 09:35
@Xatenev I used `tcpdump -w 1.pcap -nni any host 5.57.59.196 &` and then run my script, then I noticed the 1.pcap is empty.... strange... looks like it can't catch any packet apart from my own... — albertma789, Jul 03 '18 at 10:03
@Xatenev is there a verbose mode to see what file_get_contents() is doing behind the scene? — albertma789, Jul 03 '18 at 10:04
@Xatenev ok I got it. Please see below: `reading from file 1.pcap, link-type EN10MB (Ethernet)` `18:13:15.239586 IP debian.59581 > 5.57.59.196.https: Flags [S], seq 2760997044, win 29200, options [mss 1460,sackOK,TS val 2540286 ecr 0,nop,wscale 7], length 0` `18:13:16.235896 IP debian.59581 > 5.57.59.196.https: Flags [S], seq 2760997044, win 29200, options [mss 1460,sackOK,TS val 2540536 ecr 0,nop,wscale 7], length 0` `18:13:18.239889 IP debian.59581 > 5.57.59.196.https: Flags [S], seq 2760997044, win 29200, options [mss 1460,sackOK,TS val 2541037 ecr 0,nop,wscale 7], length 0` — albertma789, Jul 03 '18 at 10:10
@Xatenev the captured results of a wget session to the same server is similar. — albertma789, Jul 03 '18 at 10:16
the TCP sequence number does not increase (2760997044) - seems like your packets do not get through to the other host. Packet lengths are 0, too. Can you try a `traceroute` or `telnet` to the given host? — IVO GELOV, Jul 03 '18 at 11:04

score 0 · Answer 1 · answered Jul 04 '18 at 03:26

Finally I got the problem fixed by following someone's comment on this post

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

I found the following in the Linux Advanced Routing & Traffic Control HOWTO article.

/proc/sys/net/ipv4/tcp_timestamps

Timestamps are used, amongst other things, to protect against wrapping sequence numbers. A 1 gigabit link might conceivably re-encounter a previous sequence number with an out-of-line value, because it was of a previous generation. The timestamp will let it recognize this 'ancient packet'.

However I have no idea why it works. Can someone please explain?

file_get_contents() works differently on different machines

1 Answers1