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
even I am facing this issue. Has there been any recent change?
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.
@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.
@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.
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.
Hi @Greg-DB, any update on the roll back of "Transfer-Encoding: chunked"?
@rdee The rollback is still planned, but was delayed for unrelated reasons.
@rdee The rollback has been started. It will take some time before it's fully deployed though.
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?
@rdee I don't have an updated timeline right now. The original plan was to revert on 3/1, but I'll post if/when there are any changes.
Update: we have extended the timeline and are planning to keep the current behavior until at least 3/14.
Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this on 3/14. (Regardless, for HTTP compatibility in general, we still recommend you make sure your HTTP clients support both types.) Hope this helps!
