New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
omau opened this Issue Oct 26, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@omau

omau commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Oct 26, 2017

Member

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

Member

bagder commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jay

jay Oct 26, 2017

Member

@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	
Member

jay commented Oct 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@monnerat

monnerat Oct 27, 2017

Collaborator

@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.

Collaborator

monnerat commented Oct 27, 2017

@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 added a commit that referenced this issue Oct 29, 2017

cli tool: in -F option arg, comma is a delimiter for files only
Also upgrade test 1133 to cover this case and clarify man page about
form data quoting.

Bug: #2022
Reported-By: omau on github
@monnerat

This comment has been minimized.

Show comment
Hide comment
@monnerat

monnerat Oct 29, 2017

Collaborator

Fixed by f82f952

Closing this issue

Collaborator

monnerat commented Oct 29, 2017

Fixed by f82f952

Closing this issue

@monnerat monnerat closed this Oct 29, 2017

@lock lock bot locked as resolved and limited conversation to collaborators May 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.