cURL parameter compatibility

[allevo]

Hi!
To use autocannon, I commonly follow the steps:

1. invokes the endpoint with a cURL, adjusting the input parameters and checking the response
2. convert every cURL parameters into autocannon ones
3. invokes the endpoint with autocannon with -a 1 -c 1 and see if the status code is 200 (hoping the response body is the same)
4. invokes the endpoint with autocannon with parameters for load test

Unfortunately, the parameter conversion is not easy, and step 3 requires more retries.
My desiderata would be to replace the cURL command with autocannon without parameter conversion.
In this way, we can remove some pains during the tests.

Other considerations:

• Another path I commonly take is to copy the cURL directly from the browser network tab.
• We can start from the common cURL parameters like header and request body.

I can take this by providing a PR if you are interested in this enhancement, but please give me some input on where to start.

What do you think?

[mcollina]

That's what would need to be changed:

autocannon/autocannon.js

Lines 107 to 116 in ac8169c

	let argv = subarg(argvs, {
	boolean: ['json', 'n', 'help', 'renderLatencyTable', 'renderProgressBar', 'renderStatusCodes', 'forever', 'idReplacement', 'excludeErrorStats', 'onPort', 'debug', 'ignoreCoordinatedOmission', 'verbose'],
	alias,
	default: defaults,
	'--': true
	})
	// subarg does not convert aliases in sub arguments
	argv = generateSubArgAliases(argv)
	argv.url = argv._.length > 1 ? argv._ : argv._[0]

.

I would also recommend to modernize this using node core utility for parsing arguments.

[allevo]

Is it ok for you having a breaking change with the cli ?

[mcollina]

If we can support commands (as aliases) that would be great. If not I'm happy to support the brekage, but I would like to see the impact before confirming.

[allevo]

I had a parameters review. Some conflicts would be excellent to resolve somehow. Here is a recap below:

1. --data is used to send the request body. Now autocannon only handles -b, so I added it as an alias
2. if the request body is present, the request method is set to POST if not explicitly given. I put the method to POST if body is given. breaking change
3. -v puts the curl in debug mode, dumping the request (whole request, not just the body) and the response (whole response, not just the body). Instead, autocannon uses this parameter as an alias of --version. breaking change
4. --data @filepath is not supported by autocannon. possible breaking change
5. -X is used to specify the http request method. I put it as an alias
6. I don't want to support --location because it could be hard to implement. Anyway, autocannon ignores unknown parameters, so it is okay.
7. By default, --data puts application/x-www-form-urlencoded as the content type.
8. --data if read from a file, remove all the \n and similar stuff.
9. --data-binary sends the data as is without removing \n and similar stuff.

Considering the above list, I see two ways to avoid a breaking change:
a. use a different node bin, like autocannon-curl
b. put a --curl-compatibility (or similar) parameter to tell autocannon to parse the parameters as curl-like params.
c. put a --from-curl-command parameter to tell the rest of the strings are a curl command. Just an example autocannon -c 10 -d 10 --from-curl-command curl -X POST -d @foo "https://httpbin.org/anything" -H "accept: application/json". This will used the parameters before the --from-curl-command as autocannon parameters, the after ones as curl parameters.

I also started the implementation. If you are interested, I'll also open a PR!

Let me know how you prefer to proceed.

[mcollina]

I don't see any major disruption here. I'm ok to ship a major with those changes.