Cannot use json with several values from command line as multi-part upload

[omau]

I did this

curl -F a="{\"field1\":\"value1\",\"field2\":\"value2\"}" url

I expected the following

curl: (6) Could not resolve host: url

Instead I received:

Warning: garbage at end of field specification: ,"field2":"value2"}
curl: (6) Could not resolve host: url

(since 7.56.0, still works fine with 7.55.1)

curl/libcurl version

curl 7.56.1 (x86_64-pc-linux-gnu) libcurl/7.56.1 OpenSSL/1.1.0f zlib/1.2.11 libpsl/0.18.0 (+libicu/59.1) libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Release-Date: 2017-10-23
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

operating system

Arch Linux

[bagder]

Feel like taking a look at this @monnerat ? I could verify that it works with my 7.55.1 but not with git master...

[jay]

@monnerat It seems get_param_part/get_param_word checks for outer quotes before splitting but there aren't any (since the argument is passed to curl as a={"field1":"value1","field2":"value2"}), so then it splits on the comma.

get_param_part *str input:
{"field1":"value1","field2":"value2"}

get_param_part calls: get_param_word *str output:
,"field2":"value2"}
(note function is documented "str either point to string end or point to any of end chars." and ,; are end chars)

get_param_part returns: *pdata output:
{"field1":"value1"

and that is all that is sent. but was it intended to split the field if it's not recognized as opposed to ;type or something

>	curld.exe!get_param_part(OperationConfig * config, char * * str, char * * pdata, char * * ptype, char * * pfilename, char * * pencoder, curl_slist * * pheaders)  Line 213	C
 	curld.exe!formparse(OperationConfig * config, const char * input, curl_mime_s * * mimepost, curl_mime_s * * mimecurrent, bool literal_value)  Line 800 + 0x21 bytes	C
 	curld.exe!getparameter(const char * flag, char * nextarg, bool * usedarg, GlobalConfig * global, OperationConfig * config)  Line 1611 + 0x2d bytes	C
 	curld.exe!parse_args(GlobalConfig * config, int argc, char * * argv)  Line 2108 + 0x19 bytes	C
 	curld.exe!operate(GlobalConfig * config, int argc, char * * argv)  Line 2020 + 0x11 bytes	C
 	curld.exe!main(int argc, char * * argv)  Line 261 + 0x11 bytes	C
 	curld.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes	C
 	curld.exe!mainCRTStartup()  Line 371	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

[monnerat]

@jay: many thanks for the additional info.

First, I think this particular case is a very good candidate for the --form-string option.

Next, I agree the comma should'nt be a delimiter except when value starts with @.

Please note there are minor differences from 7.55. Maybe they should be documented:

• Of course, new ;keywords are processed. There can even be spaces between ; and keyword.
• Leading and trailing spaces are stripped from value if unquoted.
• String and <file values can also be quoted: this allows easier escaping when using ;keywords, as a="value;type=whatever";type=text/plain, which was not possible in 7.55.
• Unquoted string values may not contain a semicolon.

If these differences are acceptable to you, I suggest (and intend) to simply remove comma as a delimiter except for @ fields.

[monnerat]

Fixed by f82f952

Closing this issue