You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
OTA for CC3200 Corrupted Download file.
We are using dropbox to host update files for a hardware device that uses a cc3200. Last week our devices were no longer able to retrieve a file update file from dropbox. When we test the download it is returning an invalid file of the correct size.
Were any changes made in the past few weeks that would cause this to happen?
What were these changes?
Have any other customers reported this issue?
We are confident that this is a dropbox issue, we ran a local test redirecting traffic to a local server that returns the same file and everything works. But if we download the same file from dropbox it fails.
You can see that in the file dropbox returns it is appending a few bytes at the front.
Thanks for checking.
TJ
Update: we have extended the timeline and are planning to keep the current behavior until at least 3/14.
- Greg-DB
Dropbox Staff
From this description, it sounds like this is due to recent updates to the server back-end for some Dropbox functionality to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients are supposed to automatically handle this, but it's possible yours doesn't.
Please note that Dropbox does not guarantee which encoding will be used or that the "Content-Length" HTTP response header will always be present on the responses for these URLs. When the server is using "Transfer-Encoding: chunked" for the response, "Content-Length" is omitted. While the Dropbox servers use the HTTP protocol, exactly which features they use may change over time.
If your client isn't properly decoding the HTTP message, it could corrupt the data you save. That is, it would be incorrectly saving the raw response body, including some additional HTTP chunk data, as the file.
If that's the issue, you should update your client/code to support "Transfer-Encoding: chunked" (and not assume the "Content-Length" response header will be present). Or, switch to HTTP/2, where "Transfer-Encoding: chunked" is not used (and the "Content-Length" response header should be present).
However, in order to temporarily accommodate clients that don’t properly support automatically handling “Transfer-Encoding: chunked”, we’re temporarily rolling back this change, so that these links will no longer use “Transfer-Encoding: chunked” and will instead return “Content-Length” on HTTP/1.1. We will begin rolling that out shortly, likely today. That will be in place until around 3/1. At that point, we will begin using “Transfer-Encoding: chunked” and no longer returning “Content-Length” on HTTP/1.1 again.
Going forward, please ensure that your clients are able to automatically handle both chunked encoding and non-chunked encoding automatically.
Can you let me know when that rollback was completed? We are still having issues updating the devices.
We will not be able to update all of our devices in the field, used by consumers, by 3/1. This method, along with the sample code, of doing OTA Updates was supplied by texas instruments for the CC32XX chipset. While we understand that dropbox does not guarantee which encoding will be used you should be aware that this change will likely affect a lot of devices. Likely there are millions of devices in the wild that are going to have this issue if you change back to chunk encoding. Some of these devices, such as ours, only receive updates occasionally and they will be unware that this issue affects them until months from now.
justindaw wrote:...
You can see that in the file dropbox returns it is appending a few bytes at the front.
...
🙂 Not only at the front, for sure! There are 2 bytes at the end too, at least. May be some more inside.
34 30 30 30 0d 0a 🡓 🡓 🡓 🡓 🡓 🡓 4 0 0 0 CR LF
The above means you have a chunk of data. Chunk size is 4000 Bytes and at the end are 2 more bytes (Carriage return and Line feed). If that chunk is the entire data, that's all. Otherwise follows new chunk's packet - new size (encoded to ASCII digits as in your example) and CR LF pair, actual chunk of data, and ending CR LF pair. The last repeats as many times as need to transfer all data.
Hope this sheds some light on chunked transfer encoding. 😉
About Discuss Dropbox Developer & API
Make connections with other developers
