Error parsing cURL command

[caleb-lindgren]

Thanks for this awesome tool! It's super useful. I just found a particular cURL command that it wasn't able to parse, so I thought I'd let you know. Here's the command:

curl -X GET "https://reactome.org/ContentService/data/mapping/UniProt/PTEN/pathways?species=Homo%20sapiens" -H "accept: application/json"

If I take out the header at the end it can parse it fine. So I'm not sure what's going on. I figured out the requests command for myself just fine, but I thought you'd like to know that the parser had a problem with it.

[anaf007]

My parsing is wrong, too.

curl -v -X POST https://api.sandbox.paypal.com/v1/customer/disputes/PP-D-21692/provide-evidence -H "Content-Type: multipart/related; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -H "Authorization: Bearer A21AAGOs8Yauykf6g-avc0v7kdQVJipuyE2NuRdbA7VbOxRDSQLMBUs3HTYbe3mxkZng5VhLuQUhDplE6ZSxjWSSRhAwgDwzg" -F 'input={"evidences": [{ "evidence_type": "PROOF_OF_FULFILLMENT", "evidence_info": { "tracking_info": [ { "carrier_name": "OTHER", "tracking_number": "122533485" } ] }, "notes": "Test"} ]};type=application/json' -F '[email protected]'

[romadrutskii]

Thanks for this awesome tool! It's super useful. I just found a particular cURL command that it wasn't able to parse, so I thought I'd let you know. Here's the command:

curl -X GET "https://reactome.org/ContentService/data/mapping/UniProt/PTEN/pathways?species=Homo%20sapiens" -H "accept: application/json"

If I take out the header at the end it can parse it fine. So I'm not sure what's going on. I figured out the requests command for myself just fine, but I thought you'd like to know that the parser had a problem with it.

It works fine with a header.

[romadrutskii]

My parsing is wrong, too.

curl -v -X POST https://api.sandbox.paypal.com/v1/customer/disputes/PP-D-21692/provide-evidence -H "Content-Type: multipart/related; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -H "Authorization: Bearer A21AAGOs8Yauykf6g-avc0v7kdQVJipuyE2NuRdbA7VbOxRDSQLMBUs3HTYbe3mxkZng5VhLuQUhDplE6ZSxjWSSRhAwgDwzg" -F 'input={"evidences": [{ "evidence_type": "PROOF_OF_FULFILLMENT", "evidence_info": { "tracking_info": [ { "carrier_name": "OTHER", "tracking_number": "122533485" } ] }, "notes": "Test"} ]};type=application/json' -F '[email protected]'

What is the problem do you have?

[verhovsky]

Whatever the issue was, @caleb-lindgren's request seems to convert correctly now. ~~Edit: maybe the issue was that the name of the header is accept, when usually headers are supposed to be title-cased, i.e. Accept.~~

However, @anaf007's request is still an issue. The problem is that it doesn't parse the value of -F correctly

-F 'input={"evidences": [{ "evidence_type": "PROOF_OF_FULFILLMENT", "evidence_info": { "tracking_info": [ { "carrier_name": "OTHER", "tracking_number": "122533485" } ] }, "notes": "Test"} ]};type=application/json'

should interpret the ;type=application/json as a header for that file specifically, see the documentation for -F:

You can also tell curl what Content-Type to use by using 'type=', in a manner similar to:

curl -F "[email protected];type=text/html" example.com

but curlconverter gets confused by this input because it just calls JavaScript's .split('='):

files = {
    'input': (None, '{"evidences": [{ "evidence_type": "PROOF_OF_FULFILLMENT", "evidence_info": { "tracking_info": [ { "carrier_name": "OTHER", "tracking_number": "122533485" } ] }, "notes": "Test"} ]};type'),

at a minimum it shouldn't have the ";type" at the end of the string. Ideally it should generate code that sets the correct content type for 'input'.

#303 might end up addressing this, but -F actually has the most complicated parsing logic of any option (we can't just split(';') because a ; could appear in the input if the input is quoted), so no promises.

@anaf007 in the future, it would've been better to open a separate issue.