Dropbox media can't be access by azure blob

Can you clarify where exactly you're seeing the 500 error? Is that coming from the Dropbox servers, or some other part of the process? It would be helpful if you can show the error/output in context. Thanks!

It's not particularly from dropbox. but It was working some months ago and now not getting the proper bytes. So Can you just let me know that dropbox changed any URLs or any security for third-party APIS?

Thanks, in that case if the 500 isn't coming from Dropbox itself, this may be because we recently updated the server back-end for these links to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients should automatically handle this, but it's possible yours doesn't.

Are you able to retrieve any specific error message or output from your HTTP client? That would help confirm that.

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

Hi Greg,

Thanks for this information. I think the issue related to the Transfer-Encoding: chunked. Can we have any other URL which is working as past? So we can use that URL to download the full video. Also, let me know if you have any other ways.

Thanks.

There isn't another link type that I can refer you to that won't necessarily use this transfer encoding. "Transfer-Encoding: chunked" is part of the HTTP spec so I can't guarantee it won't be used for any particular URL. You should update your client to support this, and/or HTTP/2.

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.

Greg-DB  - Thanks for Inform. I have a question when I start to download the media by ourselves to prevent this problem in the future.

Currently, we get the X-Dropbox-Content-Length in the header of the Head methods. So can you just inform us that header will be as it is in the future or it will be changed? If we get this type of header then we can download media in chunks with that length. Let me know if you want something from my side.

The "X-Dropbox-Content-Length" header is not part of the HTTP spec and is not officially documented by Dropbox, so we can't recommend assuming that will always be present. I'm sending this along as a request to offer a guarantee on that, but I can't promise if that will be done.

Got it. If possible if dropbox sends any header related to content length for the Head request then it will be good for all developers who try to download the dropbox media in chunks.

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 as previously planned. (Regardless, for HTTP compatibility in general, we still recommend you make sure your HTTP clients support both types.) Hope this helps!