cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: The /upload behavior has been changed ?

The /upload behavior has been changed ?

wen_hsiao
Explorer | Level 4
Go to solution

Recently,  we received many feedbacks from our product users that the filename (use /upload) has become garbled. We found the "path" decode behavior might be changed by dropbox server.

For Example: (the current behavior)

curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer access_token" \
--header "Dropbox-API-Arg: {\"path\": \"/RICE/我的檔案\",\"mode\": \"add\",\"autorename\": false,\"mute\": false}" \
--header "Content-Type: application/octet-stream" \
--data-binary @test.pdf

{"name": "\u00e6\u0088\u0091\u00e7\u009a\u0084\u00e6\u00aa\u0094\u00e6\u00a1\u0088", "path_lower": "/rice/\u00e6\u0088\u0091\u00e7\u009a\u0084\u00e6\u00aa\u0094\u00e6\u00a1\u0088", "path_display": "/RICE/\u00e6\u0088\u0091\u00e7\u009a\u0084\u00e6\u00aa\u0094\u00e6\u00a1\u0088", "parent_shared_folder_id": "4082639392", "id": "id:Io0h0kFRW8sAAAAAANBUdA", "client_modified": "2019-10-09T08:32:39Z", "server_modified": "2019-10-09T08:32:39Z", "rev": "5947620b4879df3582220", "size": 38908, "sharing_info": {"read_only": false, "parent_shared_folder_id": "4082639392", "modified_by": "dbid:AADoF7JHXmoPd6Rx2X-1h0qzHUgXhnQfiH0"}, "is_downloadable": true, "content_hash": "cae9af2c924e769d376ed2143b0e8b0195b689764ac01be0ecc8e72b9a1feeb1"}

the decoded response "name" will be : æˆ‘的檔案

but in the past, the response "name" should be: \u6211\u7684\u6a94\u6848

which is the encoded string of "我的檔案"

 

 

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

There was a change on our server stack that affected how we handled HTTP headers without proper encoding. That resulted in malformed file paths/names. We've reverted that change, so that should be working again, but please make sure your headers get encoded properly.

View solution in original post

12 Replies 12

Greg-DB
Dropbox Staff
Go to solution

Thanks for the report! We'll look into whether something changed, but note that whenever you supply non-ASCII characters in HTTP headers, such as for the /upload endpoint, you should first encode them. We have documentation on this here:

https://www.dropbox.com/developers/reference/json-encoding

For example, you can see how this is done by the API v2 Explorer: (be sure to click "Show Code")

https://dropbox.github.io/dropbox-api-v2-explorer/#files_upload

 

Greg-DB
Dropbox Staff
Go to solution

This should be working again.

However, please note that sending non-ASCII characters in HTTP headers is not officially supported, so please make sure to encode them as documented.

wen_hsiao
Explorer | Level 4
Go to solution

We would follow the documentation,

but the example request I stated works well for a long time (at least a year) ,

Have you changed the behavior recently?

Greg-DB
Dropbox Staff
Go to solution

There was a change on our server stack that affected how we handled HTTP headers without proper encoding. That resulted in malformed file paths/names. We've reverted that change, so that should be working again, but please make sure your headers get encoded properly.

MReizinho
Explorer | Level 4
Go to solution

Dear @Greg-DB ,

I'm one of the people that is experiencing these problems, probably one of @wen_hsiao product users.

I did some exhaustive testing and I'm sorry to say that the problem still remains.

Something has changed for sure: now it doesn't happen with ALL the files/folders with non-ASCII characters like it happened last week, but it still happens in most cases. The change to your server stack that affected the processing of the HTTP headers wasn't reverted completely.

For us, end users, I can only think of two solutions:

1. Dropbox reverts correctly the changes applied last week

2. The manufacturer of the product I purchased updates its client to correctly process HTTP headers

Meanwhile my corporate network remains inoperative.

Please help us out. Thank you very much.

Greg-DB
Dropbox Staff
Go to solution

@MReizinho Thanks for the report. I just double checked the issue via the code shared in the original comment on this thread, and it is currently working properly.

If something is currently not working as expected, please share the code or steps to reproduce the issue and we'll look into it.

Either way, it is important that the developer of the app update it to properly encode HTTP headers.

MReizinho
Explorer | Level 4
Go to solution

Dear @Greg K. ,

Thank you very much for your prompt reply. I do believe that the code above is now working. But there are so many non-ASCII characters that perhaps some just fall into the loop. That would explain why the behaviour has changed from last week to ALL folders/files to just some.

Unfortunately, I'm not a developer like @wen_hsiao and don't know how to give you the code in API "language". What I can give you is a path and filename of some of my today errors. Perhaps you can run it and see if it works on your side:

\CONCURSOS PARTICULARES\2019\19.189 - Colombo Mobiliário\02 - ORCAMENTO\PROPOSTA ENVIADA\QUANTIDADES - COLOMBO (2019-07-16).xlsx

It was converted to:

\CONCURSOS PARTICULARES\2019\19.189 - Colombo Mobiliário\02 - ORCAMENTO\PROPOSTA ENVIADA\QUANTIDADES - COLOMBO (2019-07-16).xlsx

Another example:

\CONCURSOS PARTICULARES\2019\19.203 - Colombo Escritorios\06 - PROJECTOS\2_25-09-2019 - Pojeto segurança\

It was converted to:

\CONCURSOS PARTICULARES\2019\19.203 - Colombo Escritorios\06 - PROJECTOS\2_25-09-2019 - Pojeto segurança\

Hope it's useful. Please let me know if I can help in any way.

Thank you.

 

Greg-DB
Dropbox Staff
Go to solution

@MReizinho Thanks for the sample! I just gave those two a try though and they both uploaded properly for me just now, even without applying the proper encoding:

curl -X POST https://content.dropboxapi.com/2/files/upload \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Dropbox-API-Arg: {\"path\": \"/CONCURSOS PARTICULARES/2019/19.189 - Colombo Mobiliário/02 - ORCAMENTO/PROPOSTA ENVIADA/QUANTIDADES - COLOMBO (2019-07-16).xlsx\",\"mode\": \"add\",\"autorename\": false,\"mute\": false}" \
    --header "Content-Type: application/octet-stream" \
    --data-binary "some data"

That returns the following with the expected value:

{"name": "QUANTIDADES - COLOMBO (2019-07-16).xlsx", "path_lower": "/concursos particulares/2019/19.189 - colombo mobili\u00e1rio/02 - orcamento/proposta enviada/quantidades - colombo (2019-07-16).xlsx", "path_display": "/CONCURSOS PARTICULARES/2019/19.189 - Colombo Mobili\u00e1rio/02 - ORCAMENTO/PROPOSTA ENVIADA/QUANTIDADES - COLOMBO (2019-07-16).xlsx", "id": "id:25N5ksooX-sAAAAAAAOCZA", "client_modified": "2019-10-14T18:11:02Z", "server_modified": "2019-10-14T18:11:03Z", "rev": "594e2ca6a7afd021eccc7", "size": 9, "is_downloadable": true, "content_hash": "149078105941cd1edda0ec5a568fc1d178661b6441831c3647d88f41f7dfc886"}

And that prints out properly as:

{
  "name": "QUANTIDADES - COLOMBO (2019-07-16).xlsx",
  "path_lower": "/concursos particulares/2019/19.189 - colombo mobiliário/02 - orcamento/proposta enviada/quantidades - colombo (2019-07-16).xlsx",
  "path_display": "/CONCURSOS PARTICULARES/2019/19.189 - Colombo Mobiliário/02 - ORCAMENTO/PROPOSTA ENVIADA/QUANTIDADES - COLOMBO (2019-07-16).xlsx",
  "id": "id:25N5ksooX-sAAAAAAAOCZA",
  "client_modified": "2019-10-14T18:11:02Z",
  "server_modified": "2019-10-14T18:11:03Z",
  "rev": "594e2ca6a7afd021eccc7",
  "size": 9,
  "is_downloadable": true,
  "content_hash": "149078105941cd1edda0ec5a568fc1d178661b6441831c3647d88f41f7dfc886"
}

And here's a screenshot from the Dropbox website of the correct character:

Screenshot 2019-10-14 14.13.21.png

The same worked for the second sample:

curl -X POST https://content.dropboxapi.com/2/files/upload \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Dropbox-API-Arg: {\"path\": \"/CONCURSOS PARTICULARES/2019/19.203 - Colombo Escritorios/06 - PROJECTOS/2_25-09-2019 - Pojeto segurança\",\"mode\": \"add\",\"autorename\": false,\"mute\": false}" \
    --header "Content-Type: application/octet-stream" \
    --data-binary "some data"

That returns the following with the expected value:

{"name": "2_25-09-2019 - Pojeto seguran\u00e7a", "path_lower": "/concursos particulares/2019/19.203 - colombo escritorios/06 - projectos/2_25-09-2019 - pojeto seguran\u00e7a", "path_display": "/CONCURSOS PARTICULARES/2019/19.203 - Colombo Escritorios/06 - PROJECTOS/2_25-09-2019 - Pojeto seguran\u00e7a", "id": "id:25N5ksooX-sAAAAAAAOCag", "client_modified": "2019-10-14T18:12:24Z", "server_modified": "2019-10-14T18:12:24Z", "rev": "594e2cf477ccf021eccc7", "size": 9, "is_downloadable": true, "content_hash": "149078105941cd1edda0ec5a568fc1d178661b6441831c3647d88f41f7dfc886"}

And that prints out properly as:

{
  "name": "2_25-09-2019 - Pojeto segurança",
  "path_lower": "/concursos particulares/2019/19.203 - colombo escritorios/06 - projectos/2_25-09-2019 - pojeto segurança",
  "path_display": "/CONCURSOS PARTICULARES/2019/19.203 - Colombo Escritorios/06 - PROJECTOS/2_25-09-2019 - Pojeto segurança",
  "id": "id:25N5ksooX-sAAAAAAAOCag",
  "client_modified": "2019-10-14T18:12:24Z",
  "server_modified": "2019-10-14T18:12:24Z",
  "rev": "594e2cf477ccf021eccc7",
  "size": 9,
  "is_downloadable": true,
  "content_hash": "149078105941cd1edda0ec5a568fc1d178661b6441831c3647d88f41f7dfc886"
}

And here's a screenshot from the Dropbox website of the correct character:

Screenshot 2019-10-14 14.13.36.png

Can you double check that you're still seeing the issue on new uploads being sent now? If so, please work with the developer of the app to reproduce the issue and share steps to reproduce it with us. Thanks!

MReizinho
Explorer | Level 4
Go to solution

I can confirm that those two folders and more with similar names were not correctly cretaed/uploaded today at aproximately 18:00 GMT

Here is a screenshot with the log:

Opera Snapshot_2019-10-14_212330_cob-maia.fr1.quickconnect.to.png

The highlighted file, "1162 - SD Braga - Auto de medição nº2.xlsx" fails the upload to folder "/REDE/COBELBA/DEP OBRAS/OBRAS/1162 - SPORTS DIRECT BRAGA/08 - AUTOS DE MEDIÇÃO"

Instead new folder is created in the Dropbox cloud named "/REDE/COBELBA/DEP OBRAS/OBRAS/1162 - SPORTS DIRECT BRAGA/08 - AUTOS DE MEDIÇÃO" (not shown in the log)

The file is then uploaded to that folder. But since the file also has non-ASCII characters, the filename is also changed to "1162 - SD Braga - Auto de medição nº2.xlsx"

The client, noticing a new folder and file on the Dropbox cloud, then proceeds downloading both. Thence the tree highlighted log entries: upload failed, upload and download. 

So, for what you found out, it seems that your API is processing the non-ASCII characters correctly again like it was past week. Not parsing it with the same code as it was, but right nevertheless.

The only explanation I can think of is how the client is sending out the information to be parsed. It worked before but it does not work anymore, after the changes and roll back. Like @wen_hsiao has pointed out, I've been having this system running since 2016 without a glitch. So something has certainly changed between the client and the processed response from the API callout

I'm only hopping that when @wen_hsiao sees these posts that he can follow up and come up with an updated client.

 

Need more support?