views:

48

answers:

3

The code:

// That works pretty well
curl -d "user%5Blogin%5D=some%40email.pl&user%5Bpass%5D=testpass&user%5Bmemory%5D=on&user%5Bsubmit%5D=Login" -L -c cookie.txt http://turbobit.net/user/login


//But this PHP code doesn't

$headers = array('Content-Type' => 'application/x-www-form-urlencoded', 'Referer' => 'http://turbobit.net/');
    $postdata = array('user%5Blogin%5D' => 'some%40email.pl', 'user%5Bpass%5D' => 'test', "user%5Bsubmit%5D" => 'Login', 'user%5Bmemory%5D' => 'on');
    $cookie = "/srv/http/test/regexturbobit/cookie.txt";

    $c = curl_init('http://tutbobit.net/user/login');
    curl_setopt ($c, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
    curl_setopt($c, CURLOPT_POST, 1);
    curl_setopt ($c, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($c, CURLOPT_FOLLOWLOCATION,1);
    curl_setopt($c, CURLOPT_POSTFIELDS, $postdata);
    curl_setopt ($c, CURLOPT_COOKIEJAR, $cookie);
    $output=curl_exec($c);
    curl_close($c);
    print_r($output);

it just doesn't show anything and even dont save cookie...

+1  A: 

Try:

$postdata = 'user%5Blogin%5D=some%40email.pl&user%5Bpass%5D=testpass&user%5Bmemory%5D=on&user%5Bsubmit%5D=Login';

You shouldn't have URLencoded keys in a postdata array as they'll be URL-encoded again. Alternatively you could do:

$postdata = array(
  'user[login]' => '[email protected]',
  'user[pass]' =>  'test',
  // the rest of the vars here...
);

But note that passing an array for $postdata will not send a URL-encoded request, it will send a request with multipart/form-data encoding. From the PHP docs:

CURLOPT_POSTFIELDS

The full data to post in a HTTP "POST" operation. To post a file, prepend a filename with @ and use the full path. This can either be passed as a urlencoded string like 'para1=val1&para2=val2&...' or as an array with the field name as key and field data as value. If value is an array, the Content-Type header will be set to multipart/form-data.

So, if you pass an array, the values and keys should not already be URLEncoded.

Josh
The section piece in this answer is wrong, as it this code also sends the wrong kind of POST.
Daniel Stenberg
@Daniel: I provided code for both kinds of POST. The first example is `application/x-www-form-urlencoded` and the second is `multipart/form-data`. I also included an excerpt form the manual explaining why the second was `multipart/form-data`. And, if he's POSTing to a PHP script, most likely either method will work.
Josh
Not at all, very few server-side scripts accept either POST approach. They almost always are written to accept only one of them.
Daniel Stenberg
Your statement just disregarded nearly the entire PHP scripting language. Surely you realize that a significant number of server side scripts are written in PHP? A majority of the time, PHP doesn't care if the postdata is url or multipart encoded. The values will be in `$_POST` either way.
Josh
A: 

Try using this: http://github.com/shuber/curl

Sean Huber
A: 

When you provide the data as a hash array, the POST will not be a "normal" POST anymore but it will instead make a multipart formpost.

Multipart formposts (RFC1867) are very different than the normal -d one your command line uses.

A nice trick is to use append "--libcurl example.c" to your curl command line to get to see the C source code for what could be used to run the same operation.

Daniel Stenberg
While you're correct that `multipart/form-data` and `application/x-www-form-urlencoded` are two very different ways of encoding postdata, "the POST will not be a 'normal' POST" isn't exactly correct. It's still an HTTP POST operation, and most likely the webserver will accept either kind. The URL provided in the question works just fine with `multipart/form-data` posts.
Josh
well your response didn't even attempt to explain the differences so thus it was not at all clear that you understood or even considered them. I think that misleads anyone who reads the question and the answers, hence my clarifications.
Daniel Stenberg
I agree my response could make that more clear. I will edit it now.
Josh
@Daniel: I see you're the maintainer of the `libcurl` package which means your C-skills and your knowledge of RFCs far exceed mine... I think we agree on the fundamental concepts here and are just arguing over semantics, which is not something I want to do... and certainly not with someone who maintains what I consider to be one of the most useful libraries I've ever used. I use libcurl in my code all the time! `:-)`
Josh