https://content.dropboxapi.com/2/files/download_zip API issue

[lair]

Hi there!

First of all thank you so much for the great API! It is easy to understand and use and it is very well documented.

Now a bit of frustration.

I'm trying to get folder contents using https://content.dropboxapi.com/2/files/download_zip endpoint. Authentication, getting access token all works smoothly until it comes to the call to this endpoint. The server opens a connection, returns 200 OK status and the data starts coming. But after roughly 5 minutes server closes the connection. I observe this behavior using Dropbox Java SDK 5.1.0. I also can reproduce it with curl. The communication is aborted *always* the server after 5 minutes and a few seconds. This is not sufficient to download the contents of the directory. I only get ~150Mb of data in this time limit. Interestingly that it is always the same timeout of 5 minutes after which the server aborts the connection. Feels like this is a sort of server configuration to abort connections if they last longer than 5 minutes.

I can download the same zipped folder from Dropbox web page though. The archive is 560Mb and it takes about 40 minutes to get downloaded. BTW, when fetching folder contents from Dropbox web page Dropbox sets Content-Length header. But this header is not set when in the reply from /files/download_zip endpoint.

Values of "X-Dropbox-Request-Id" headers of failed /files/download_zip enpoint calls: 1fb3c721d5884bb1ae6df663b861752b, 8691b0e1bafa43349a8a714da20b9746, f7d5a8c7cd184cd1b23cd2d3dc7c0037, d6fa3e47bd31471c85d30da5ef991187

Typical curl output:

{ [15669 bytes data]
100 171M 0 171M 0 0 564k 0 --:--:-- 0:05:10 --:--:-- 280k* OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal because this is a curl debug build)
* multi_done
100 171M 0 171M 0 0 563k 0 --:--:-- 0:05:11 --:--:-- 271k

Please let me know if I'm missing something here. Should I add some magic headers to the request to prevent the server from canceling the connection?

[Greg-DB]

Thanks for the report! We'll look into it.

[lair]

How reliable is the use of "Range" header when fetching folder zip? Is there any guarantee that if directory contents don't change dropbox will return the same byte sequence in the response stream? My plan is to call /files/download_zip endpoint multiple times if the first fetch fails and set the "Range" HTTP header on subsequent calls to skip data that I have fetched from the endpoint already. Would this work?

[lair]

Nor reliable at all. The header is ignored. The same data is returned regardless of the value of the header.

[Greg-DB]

The issue with these requests failing at 5 minutes should be fixed now. Please try again and let me know if you're still seeing that. Thanks!