Post data is coming as hex code in curl

[Chirag008]

A simple POST request is sent with JSON Data. The created curl contains hex code instead of normal text in the request.

For eg. REST ASSURED request was (logs of rest assured)

Request method: POST
Request URI: http://dummy.restapiexample.com/api/v1/create?code=1234&name=test22
Proxy:
Request params:
Query params: code=1234
name=test22
Form params:
Path params:
Headers: Accept=/
Content-Type=application/json
Cookies:
Multiparts:
Body:
{'name':"CKB2",'salary':'123','age':'23'}

And the curl created was --
curl 'http://dummy.restapiexample.com/api/v1/create?code=1234&name=test22' -H 'Accept: /' -H 'Content-Type: application/json' -H 'Host: dummy.restapiexample.com' -H 'Connection: Keep-Alive' -H 'User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_212)' -d $'\x7b\x27\x6e\x61\x6d\x65\x27\x3a\x22\x43\x4b\x42\x32\x22\x2c\x27\x73\x61\x6c\x61\x72\x79\x27\x3a\x27\x31\x32\x33\x27\x2c\x27\x61\x67\x65\x27\x3a\x27\x32\x33\x27\x7d' --compressed -k -v

I suppose, instead of hex data, it should appear in normal text.

[dzieciou]

Looking into it. Thanks for the report.

[dzieciou]

The library was applying ANSI C Quoting (including escaping characters as hex codes) to all characters, even if only some of them required escaping. That was definitely too strict. In your case only single quote required escaping. Still I need to escape some characters, because the generated curl command will be copy-pasted on a multitude of setups by a wide range of people. I don't want the result to vary based on people's local encoding or misconfigured terminals.

Therefore, I have changed the way characters are escaped in the generated curl command.

For POSIX use ANSI-C Quoting, in particular

• escape non-printable ASCII characters either with additional backslash (\n will become \\n) or hex code
• escape single quote ' (with backslash), and at character @ (with hex code) because they have special meaning in curl
• by default, escape non-ASCII characters with hex, e.g., 'name=Administração' will become $'name=Administra\xe7\xe3o' (this can be disabled through Options#dontEscapeNonAscii).

For Windows, I kept it as it was. I optimistically assumed people will configure terminal properly here (changing code page and font to support non-ASCII characters). If there is a need to support more strict escaping for Windows, I will investigate this as well in the future.

One more change, all data are now passed through --data-binary instead of --data curl parameter, because the latter strips newline (\n) and carriage return (\r) characters. To reproduce server problems I want the request sent by the generated curl command to be as identical to the original request as possible.

For your example change will result in the following curl command:

curl 'http://dummy.restapiexample.com/api/v1/create?code=1234&name=test22'
  -H 'Accept: /' -H 'Content-Type: application/json' 
  -H 'Host: dummy.restapiexample.com' -H 'Connection: Keep-Alive' 
  -H 'User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_212)' 
  --data-binary $'{\'name\':"CKB2",\'salary\':\'123\',\'age\':\'23\'}' 
  --compressed -k -v

Is this solution OK for you?

[dzieciou]

If you want to try the fix, it's available in the branch. I will keep it for some time in a branch and then in 1.0.5-SNAPSHOT version before it is released, because the change was quite significant and I want to make sure it has not affected other areas.