Child Item

HTTP 400 Bad Request - Embedded Device

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!

Find more posts tagged with

Developers

Comments

Greg-DB

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

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

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

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.