OTA for CC3200 Corrupted Download file.

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.