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.

Discuss Dropbox Developer & API

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

HTTP 400 Bad Request - Embedded Device

HTTP 400 Bad Request - Embedded Device

SafetyLok
Explorer | Level 3

Hi,

 

Working on an embedded device, trying to add a file to Dropbox and put some data into it.

 

The operation succeeds, and my file + correct data is on dropbox. However I get a HTTP/1.1 400 Bad Request as a second response from the dropbox server.

 

The body of the message cotains:

Error (4xx) We can't find the page you're looking for.

 

 

I am doing this in a bare metal approach, and as a result I only have access to the raw data being transmitted over the secure socket:

 

(Note: I've shortended some returns to hide important info)

Firstly the upload post:

POST /2/files/upload HTTP/1.1
host: content.dropboxapi.com
Authorization: Bearer xxxxxxxxxxxxxxxxxxxxx
Content-Type: application/octet-stream
Content-Length:  18
Dropbox-API-Arg: {"path": "/SN_WIN32/test.txt","mode": "add","autorename": true,"mute": false,"strict_conflict": false}


THIS IS SOME DATA

 

Then the first response from dropbox.

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 20 Jun 2020 01:06:44 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
cache-control: no-cache
pragma: no-cache
X-Server-Response-Time: 702
X-Dropbox-Request-Id: e4f48d1218f0f1cd0af9dc01be5f0512
X-Robots-Tag: noindex, nofollow, noimageindex


17a

{"name": "test.txt", "path_lower": "/sn_win32/test.txt", "path_display": "/SN_WIN32/test.txt", "id": "id:xxxx", "client_modified": "2020-06-20T00:56:20Z", "server_modified": "2020-06-20T00:56:21Z", "rev": "xxx", "size": 18, "is_downloadable": true, "content_hash": "510320d6206ba597e7c49272954b27a2150804a12fa8073162493fca985bf971"}

0

Then the second response from dropbox.

HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 20 Jun 2020 01:06:44 GMT
Content-Type: text/html
Content-Length: 25658
Connection: close
ETag: "5ed1892e-643a"
X-Dropbox-Request-Id: b184039321d978148fc4c7e45f85646f
X-Robots-Tag: noindex, nofollow, noimageindex

<SNIP>
<div class="not-found"> <h1>Error (4xx)</h1> We can't find the page you're looking for. 
<SNIP>

 

Finally, if I try and do a file append, I get the same types of responses and my connection gets closed by Drobox.

 

Can anyone identify what I am doing wrong?

 

Thanks!

 

4 Replies 4

Greg-DB
Dropbox Staff

Can you double check you're not accidentally sending two requests? The Dropbox API shouldn't be sending two responses to a single request. 

 

Since there are two different 'X-Dropbox-Request-Id' values, it does look like the Dropbox API servers are receiving two requests.

 

Also, I'm not sure what you mean when you say you "try and do a file append". The Dropbox API doesn't offer functionality for appending to files. Can you elaborate on that?

SafetyLok
Explorer | Level 3

Hi,

 

Thanks very much for your reply.

 

I am also thinking that the issue must be another message being sent, maybe our radio module is sending a keep alive or something similar. I am 100% certain we are only sending the one message, I' have verified this via the SPI link between our MCU and the radio module.

 

I have tried our upload using cURL on the Windows command line, and I only see one response, however there is additional encrypted traffic on wireshark, and I can't be sure if other responses are arriving and cURL has already completed.

 

For the append we are using the following endpoints:

 

/2/files/upload_session/start
/2/files/upload_session/append_v2
/2/files/upload_session/finish

Is there any way of knowing why the second "400 Bad Request" would be sent?.

Does drop box offer anything like Amazon's Cloud Watch logs of what happens on the front end?

 

Thanks.

 

 

Greg-DB
Dropbox Staff

Thanks for the additional information, and clarifying that you were referring to appending to an upload session. 

 

Anyway, regardless of whether you're using the single /2/files/upload endpoint, or the upload sessions endpoints, the Dropbox API should only be sending one response per request. (I also haven't heard any other reports like this.)

 

Unfortunately, Dropbox doesn't offer a way to retrieve error logs for an app.

 

Looking at the actual headers/content of the second response you showed in your first message, it looks like that may be the generic 400 error that the Dropbox sends when a request is malformed and couldn't be understood. (It's a generic HTML error page, not specific to the API.) That does seem to support the idea that the client is sending some other request, perhaps a corrupted or partial request, that can't be interpreted as a valid API call. For example, perhaps the client is sending more data over the socket after the actual intended HTTP message for the API call, and that extra data is not properly formed as an HTTP message, resulting in the error.

SafetyLok
Explorer | Level 3

Hi,

 

We'll put this down to something wrong with the radio module.

 

We have tried two different vendors radio modules and this problem does not exist.

 

I'll call this case closed.

 

Thanks.

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    SafetyLok Explorer | Level 3
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?