Allow multiple -data parameters

[ldrozdz]

For compatibility with curl(1), allow specifying the -d | -data parameter more than once.

Form curl manpage:

If any of these options is used more than once on the same command line, the data pieces specified will be merged together with a separating &-symbol. Thus, using '-d name=daniel -d skill=lousy' would generate a post chunk that looks like 'name=daniel&skill=lousy'.

[jeremp]

The curl manpage also says that the content-type header should be transformed to application/x-www-form-urlencoded.
I understand that if we allow multiple -data then we should check that each parameter contains a key and a value separated by equals.

Do you agree ?

[ldrozdz]

Good point. This might be where we diverge from curl(1), as the internal usage which JCurl sprang from is more geared towards multipart/form-data than application/x-www-for-urlencoded. Generally, I'd like to keep JCurl liberal wrt. parameter syntax - just pass in whatever you want and have the API you call tell you if you're doing something stupid. But let me come back to you with a full response when I implement it (or see a PR).

[jeremp]

I see that the multipart/form-data case is implemented (formMap).

It may exists two options to deal with application/x-www-form-urlencoded :

1. Let the user use the -d option only once with by example name=foo&city=bar and set the right header Content-Type: application/x-www-form-urlencoded (it is the way it works today)
2. Let the user use multiple -d options and concat each of them with '&' and (optional) warn him if he sets the Content-Type header to something that is NOT application/x-www-form-urlencoded.

Whatever the chosen option we'll need to add an example in the documentation.

[ldrozdz]

Should have said it earlier, but thanks for your comments! Great to see the tool being used by someone else than myself:).

As to your suggestion, there's also application/json, which has been the main concern for this tool and is another major use case for -d. Thus, setting the content type to form-urlencoded automatically would be too limiting.

However if the content type is urlencoded, then yes, we can definitely concat multiple -d values with &.

In general, my goal would be to keep the parameter syntax as close as possible to curl(1), but not fanatically, diverging from it when I see curl too limiting or when we can provide syntax sugar that curl doesn't.