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.

---

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. 😉