'curl: What's the difference between -d and --data-binary options?

I'm trying to send a post request to a REST API. I noticed that everything works fine when I pass parameters with -d option in curl. Example:

curl "https://mywebsite.com" -d "param1=x" -d "param2=y" -u "3SUHZb0sanKWrQ"

However, if a send parameters as a json object and using --data-binary, I receive an error from the Api (as if no parameters were received). Example:

curl "https://mywebsite.com" --data-binary $'{ "param1": "x", -d "param2":"y" }' -u "3SUHZb0sanKWrQ"

I thought the two approaches had the same behavior, but I think I'm wrong. What's the difference between these two approaches?

P.S.: the second request is the curl request that I get when select copy as cURL option on Google Chrome, because the actual request is a $http.post in Angular with its data payload as a JSON object. What can I do in Angular to get it working?

var data = { 
  "param1": "x", 
  "param2": "y" 
};

$http({
    url: "https://mywebsite.com",
    method: 'POST',
    data: data
}).then(function successCallback(response){
    console.log(response);
}, function errorCallback(response){
    console.log(response);
});


Solution 1:[1]

  • -d @file or equivalently --data @file will send the file but stripping out carriage returns and newlines (and maybe also doing character set conversion)
  • --data-binary @file will send the file as-is
  • --data-raw @file will send the literal string "@file"
  • Without an initial @-sign all three behave identically, sending the following argument as a literal string.

Moreover all three set the Content-Type to application/x-www-form-urlencoded unless you override it; if you are sending JSON, you probably want to set -H 'Content-Type: application/json'.

I suggest that if you want to send a literal string from the command line, use --data-raw, and if you want to send a file, use --data-binary @file.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Robert Tupelo-Schneck