PHP File_Get_Contents() and Setting Request Headers

PHP file_get_contents() and setting request headers

Actually, upon further reading on the file_get_contents() function:

// Create a stream
$opts = [
    "http" => [
        "method" => "GET",
        "header" => "Accept-language: en\r\n" .
            "Cookie: foo=bar\r\n"
    ]
];

// DOCS: https://www.php.net/manual/en/function.stream-context-create.php
$context = stream_context_create($opts);

// Open the file using the HTTP headers set above
// DOCS: https://www.php.net/manual/en/function.file-get-contents.php
$file = file_get_contents('http://www.example.com/', false, $context);

You may be able to follow this pattern to achieve what you are seeking to, I haven't personally tested this though. (and if it doesn't work, feel free to check out my other answer)

add headers to file_get_contents in php

You can add headers to file_get_contents, it takes a parameter called context that can be used for that:

$context = stream_context_create(array(
    'http' => array(
        'method' => 'GET',
        'header' => "Host: www.example.com\r\n" .
                    "Cookie: foo=bar\r\n"
    )
));
$data = file_get_contents("http://www.example.com/", false, $context);

https headers with file_get_contents

Header are no OK... Add User-agent and it will be fine.

"User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 FirePHP/0.4\r\n".

Why? Google decides.

file_get_contents returns HTTP headers in content

I have tried this again today... and instead of headers mixed in the content, I got empty content and partial headers. This error though is a lot easier to google and lead me to this SO answer talking about a similar problem (weird file_get_contents behavior).

As the first comment hinted, changing the default socket timeout solves my problem (it was set to 60):

ini_set("default_socket_timeout", 600);

I am not quite sure how the socket can timeout since the data and the headers received seemed complete...

php file_get_contents authorization header

Your proxy will respond that authentication is required. You may scratch your head and think "but I'm providing authentication!"

The issue is that the 'header' value is only applicable to http connections. So to authenticate on a proxy, you first have to pull a file from HTTP, before the context is valid for using on FTP.

<?php 
$opts = array('ftp' => array( 
    'proxy' => 'tcp://vbinprst10:8080', 
    'request_fulluri'=>true, 
    'header' => array( 
        "Proxy-Authorization: Basic $auth" 
        ) 
    ), 
    'http' => array( 
    'proxy' => 'tcp://vbinprst10:8080', 
    'request_fulluri'=>true, 
    'header' => array( 
        "Proxy-Authorization: Basic $auth" 
        ) 
    ) 
); 
$context = stream_context_create($opts); 
$s = file_get_contents("http://www.example.com",false,$context); 
$s = file_get_contents("ftp://anonymous:anonymous@ftp.example.org",false,$context); 
?> 

How to post data in PHP using file_get_contents?

Sending an HTTP POST request using file_get_contents is not that hard, actually : as you guessed, you have to use the $context parameter.

There's an example given in the PHP manual, at this page : HTTP context options (quoting) :

$postdata = http_build_query(
    array(
        'var1' => 'some content',
        'var2' => 'doh'
    )
);

$opts = array('http' =>
    array(
        'method'  => 'POST',
        'header'  => 'Content-Type: application/x-www-form-urlencoded',
        'content' => $postdata
    )
);

$context  = stream_context_create($opts);

$result = file_get_contents('http://example.com/submit.php', false, $context);

Basically, you have to create a stream, with the right options (there is a full list on that page), and use it as the third parameter to file_get_contents -- nothing more ;-)

As a sidenote : generally speaking, to send HTTP POST requests, we tend to use curl, which provides a lot of options an all -- but streams are one of the nice things of PHP that nobody knows about... too bad...

file_get_contents fails, but POST request is made successfully

After a few months I finally found the reason why this was happening.
The worst aspect of this is that I am familiar with error_reporting(E_ALL) and ini('error_notice',1) but I completely forgot about it. I did learn about var_dump($http_response_header) so there is that.
Honestly it was in the documentation and I should have found it sooner. Oh well.

I quote myself

With post requests that do not have session headers I do not have any problem, but once I needed these and tried sending them, I hit a roadblock

I was not familiar exactly with how session mechanics work in general, so i mostly ignored the documentation until I found it a few minutes ago. I refer to session_write_close as what I should have read before diving into sessions (or more specifically, attempting to open multiple sessions in a chain of requests (that I thought of as a single request)):

session data is locked to prevent concurrent writes only one script may operate on a session at any time

In my submit.php I open the session to access some variables. I basically forgot to close it before making a new request which itself attempted to modify session data. The fix was to use session_write_close() right before post_request().

Thank you to all who commented.

---

Related Topics