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...
Update: we have extended the timeline and are planning to keep the current behavior until at least 3/14.
Greg-DB
Dropbox Staff
Dropbox StaffFrom 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.
About Discuss Dropbox Developer & API
Make connections with other developers
