Re: Error in call to API function "files/upload": HTTP header "Dropbox-API-Arg":

I'll be happy to help with any issues you're having with the Dropbox API, but I'll need some more information. Please reply with:

• the steps to reproduce the issue, including relevant code snippet(s), but don't include any access or refresh token(s)
• the full text of any error or unexpected output

this is my Swift code:

    case .Upload:

        var optionsStr = "{\"path\": \"PATH_PLACEHOLDER\",\"mode\": \"add\",\"autorename\": AUTORENAME_PLACEHOLDER, \"mute\": false,\"strict_conflict\": false}"

        optionsStr = optionsStr.replacingOccurrences(of: "PATH_PLACEHOLDER", with: remotePath!)

        let autoRename = autoRenameOnServer ? "true" : "false"

        optionsStr = optionsStr.replacingOccurrences(of: "AUTORENAME_PLACEHOLDER", with: autoRename)

        #if DEBUG

        print("header:   ", optionsStr, "\n")

        #endif

        request.setValue(optionsStr,                 forHTTPHeaderField: "Dropbox-API-Arg")

        request.setValue("application/octet-stream", forHTTPHeaderField: "Content-Type")

And I send it AS other cases (for example LIST)

the above code is for uploading.

As said, it worked a couple of weeks ago and for more than 2 years.

SO the unique reason is Siem Apis is changed OR other inner things, but NO decent details.,

to be cleat: after this code we issued the USUAL, beloved, apple-endorsed code:

  let session = URLSession.shared

    let task = session.dataTask(with: request as URLRequest, completionHandler: {data, response, error -> Void in

     ......

would be useful alo if Your programmers can send back some simular code (shell scripts..) I can run via MAC/Unix/Linux bash to get the same result uploading a file.

For reference, the documentation for /2/files/upload includes a basic example of how you might call curl in a shell to perform an upload. The API Explorer can also be useful for prototyping and testing calls. (Click "Show Code" to see an example of what the code would look like.)

Anyway, the /2/files/upload endpoint is a "Content-upload" style endpoint, so it takes the parameters as JSON in the "Dropbox-API-Arg" header. In your code I see you're building that JSON by replacing portions of a pre-existing string. I recommend using actual JSON writing functionality (for instance, provided by your platform or a library) to build that instead, as that should be less error prone.

For instance, it's possible I see you're inputting the remotePath value, and it's possible that value has changed to something that is causing your code to produce invalid JSON, such as to include some character that needs to be escaped.

When putting these values in the header, make sure you're encoding them properly. We have a documentation page here that explains what needs to be escaped, including an example written on Swift at the bottom. Check that out and make sure you're building and encoding your JSON string properly as shown there.

sorry, BUT I DID read all docs, so ls don't say to read docs. Pls respond Wirth TECH answers.

From Your answer I clearly understand you dint know swift, you assumption about string function re COMPLETELY wrong.

in detail I am USING "using actual JSON writing functionality (for instance, provided by your platform or a library)": as every serious programmers knows 

JSON is bases ion strings.

"For instance, it's possible I see you're inputting the remotePath value, and it's possible that value has changed to something that is causing your code to produce invalid JSON, such as to include some character that needs to be escaped." is completely technically wrong.

"remotePath" is a let (const in C/C++) so NOT possibile.

About ecaping as said above I did escaped reading your docs. I did validate it and it si correct:

{"path": "/OUT/aaaaa＿000.jpg","mode": "add","autorename": true, "mute": false,"strict_conflict": false}

I will giver a try to escaping, BUT as said, it worked for months in production.

I was referring to using something like JSONSerialization.data to build the JSON string from a dictionary for you, like in our example.

Regarding the remotePath value, while that may be a constant in your code (though you did not share where that is defined), is it possible you've changed what you assign to it in your code at some point?

I see in your latest comment that you included an example of the JSON string you're building, showing the path as "/OUT/aaaaa＿000.jpg". Looking at that carefully, I see that the "＿" character is not actually an ASCII underscore, but rather a Unicode character named "Fullwidth Low Line" (U+FF3F). That being the case, you will need to apply the encoding as documented, otherwise you'll run in to an error.

I just tried this myself and confirmed that running your code as shown with that character does cause a failure, but using the documented code to serialize and encode the parameters does work.

1) You wrote: "I was referring to using something like JSONSerialization.data to build the JSON string from a dictionary for you, like in our example.'

I Did write and teste din other environments and it worked, I have extensive Unit testing about.

2) d "Fullwidth Low Line" (U+FF3F).

3 consideration:

2a) it WORKED for an year, so what changed?

2b) THIS should be the  1st response 

3b) why giving back such message should be a problem for backend?

I wil try Your encoding function, I will re-post. 

I got from your example :

{"field":"some_\u00fc\u00f1\u00eec\u00f8d\u00e9_and_\u007f"}

if is correct, pls fix code that does NOT compile in swift any more, as  JSONSerialization.data can throw:

    let args = ["field": "some_üñîcødé_and_\u{7F}"]

        if let jsonData = try? JSONSerialization.data(withJSONObject: args){

            let encodedArgs = asciiEscape(utf8Decode(jsonData))

            print(encodedArgs)

        }

I can't say exactly what may have changed recently. The need to encode these values in HTTP headers has existed for a long time, so perhaps the path value itself was changed or the client network stack changed to expose this issue.

The issue was not immediately apparent based on your initial report, but I was sure to refer you to the relevant documentation and example once it was.

The value sent by the client needs to be properly encoded in order for the backend to be able to parse it.

And thanks for letting me know about the example! I'll ask the team to update that.