Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Forum Discussion
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 40...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorCan 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?
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.
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.
About Discuss Dropbox Developer and API
Explore Dropbox Developer & API discussions with developers like you.
