cURL ignores options

Question

The following cURL configuration works fine on my local machine using cURL 7.30.0:

$curl = curl_init();

curl_setopt_array($curl, array(
    // Just showing the noteworthy options here.
    CURLOPT_HTTPHEADER   => array("Content-Type: application/x-www-form-urlencoded")
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_0,
    CURLOPT_COOKIE       => "foo=bar",
));

$response = curl_exec($curl);
curl_close($curl);

Excerpt of the debugging output:

> GET / HTTP/1.0
Host: example.com
Accept: */*
Cookie: foo=bar
Content-Type: application/x-www-form-urlencoded

Now I run the same code on a shared hosting environment with cURL 7.19.7 and get:

> GET / HTTP/1.1
Host: example.com
Accept: */*
Content-Type: application/x-www-form-urlencoded

Basically cURL is working 99% fine, but ignores the forced HTTP version and cookie string. Is the hosting company running a configuration that blocks these features? Is the cURL version they are running too old? What's going on here?

Check the version of CURL running at both. Also, if you're making HTTP requests from PHP I'd recommend against cURL and in favor of a better more modern HTTP client like https://github.com/rdlowrey/Artax — Benjamin Gruenbaum, Jun 21 '14 at 21:14
Thanks Benjamin. I've added version numbers to the question. Thanks for the tip too, bookmarked it. I'm improving existing cURL code right now though, so it'd be easier to solve this issue for my current project than rewrite the whole thing. — Robbert, Jun 21 '14 at 21:21
Have you asked the support dept at the hosting company? They may shed some light on your issue. I must say that i appreciate why you are puzzled by the different results returned by 'cUrl' in what appear to be similar circumstances. — Ryan Vincent, Jun 21 '14 at 21:45
I'm waiting on a reply from the hosting company Ryan, but SO is usually a gazillion times quicker and more detailed :). — Robbert, Jun 21 '14 at 21:57
I really cannot see how this could be due to libcurl versions or anything. The cookie and the HTTP version functionality have been working solidly and the same for MANY years... (I wrote that code and maintain libcurl) — Daniel Stenberg, Jun 21 '14 at 21:57
Hi Daniel, honored to have you here. I guess I should conclude the hosting company is changing stuff on a configuration level then. — Robbert, Jun 21 '14 at 22:00
I found the culprit - should've done a sanity check on `curl_setopt_array` as it stops processing if a single option fails. Thanks for chiming in you three. — Robbert, Jun 21 '14 at 22:36
possible duplicate of [curl follow location error](http://stackoverflow.com/questions/2511410/curl-follow-location-error) — Giacomo1968, Jun 21 '14 at 22:38
@JakeGould though the `_FOLLOWLOCATION` option was indeed the culprit, my question and answer apply to any case where the return value of `curl_setopt_array` is handled incorrectly. Not sure if this should be marked as duplicate content. — Robbert, Jun 21 '14 at 22:56

score 2 · Accepted Answer · answered Jun 21 '14 at 22:34

I found it. curl_setopt_array quits processing options as soon as one option fails, I didn't know that. I should've checked the return value to make sure all was well.

In my case the culprit was option CURLOPT_FOLLOWLOCATION. It probably failed because the hosting provider is using safe mode, which disables the follow 301/302 feature.

$curl = curl_init();

$check = curl_setopt_array($curl, $options);

if(!$check)
    die("Ye be warned: one of your options did not make it.");

$response = curl_exec($curl);
curl_close($curl);

cURL ignores options

1 Answers1