Dropbox stopped returning Content length in the response headers.

[amitbtcs08]

Dropbox stopped returning Content length in the response headers. Any reason as to why?
When I call this from C# code, I don't get the response.ContentLength();
https://www.dropbox.com/s/a3lhvatmf7f6ys3/appv1.ipa?dl=1

[nurulqk]

even I am facing this issue. Has there been any recent change?

[Greg-DB]

I understand you're programmatically accessing Dropbox shared links, and have been relying on the "Content-Length" header being set on responses.

Please note that Dropbox does not guarantee that the "Content-Length" HTTP response header will always be present on the responses for these URLs though. For example, 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. In this case, server updates were made recently to use 'Transfer-Encoding: chunked' for HTTP/1.1 requests to these.

I'm passing this along to the team as a request to revert to returning the 'Content-Length' response header, but I can't promise if or when that might be implemented.

Either way, 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 the "Content-Length" response header should be present.

[rdee]

@Greg-DB

Is there a release note or anything for this feature change? I have notices a few thread in the forum related to this "Transfer-Encoding: chunked" change, and I have been affected by it as well. It would've been nice to get a heads up, if possible, for changes coming down the pipe. If not, a note after changes explaining what was changed would be helpful.

Thanks.

[Greg-DB]

@rdee Thanks for the feedback. This was not pre-announced as this encoding type is a part of the HTTP spec itself, and is expected to be handled by HTTP clients automatically, but I'll share this with the team.

[Greg-DB]

Update: 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 starting around 2/17. 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.

[rdee]

Hi @Greg-DB, any update on the roll back of "Transfer-Encoding: chunked"? 

[Greg-DB]

@rdee The rollback is still planned, but was delayed for unrelated reasons.

[Greg-DB]

@rdee The rollback has been started. It will take some time before it's fully deployed though.

[rdee]

Hi @Greg-DB I have noticed that the rollback has happened this morning. Do you have an estimate of how long this rollback will last?