Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
GET request to /files/download fails with "The network connection was lost"
Hi, Our app uses Dropbox's HTTP API to upload and download files. Since a few days ago, some of our app's requests are failing with "The network connection was lost". This issue was first reported...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorThanks for sharing that. Yes, unfortunately it doesn't look like there's anything else useful there.
Just to check, I also tried the curl command a few times but that also worked fine for me.
Logging the failing network requests themselves sounds like a good next step, so let us know if you're able to get anything from that.
> Logging the failing network requests themselves sounds like a good next step, so let us know if you're able to get anything from that.
Setting CFNETWORK_DIAGNOSTICS didn't give as much information as I had hoped. This is an excerpt relevant to the failed request:
default 15:15:31.519737-0700 Joplin CFNetwork Diagnostics [3:272077] 15:15:31.519 {
HTTPCookieStorage::copyCookiesForURL: <CFHTTPCookieStorage 0xredacted [0xredacted]>
Request URL: https://content.dropboxapi.com/<redacted>
MainDocument URL: null
} [3:272077]
default 15:15:31.519624-0700 Joplin CFNetwork Diagnostics [3:272076] 15:15:31.519 {
AddCookies Continue: request GET https://content.dropboxapi.com/<redacted>
HTTPProtocol: Task: 0xredacted
} [3:272076]
default 15:15:31.519507-0700 Joplin CFNetwork Diagnostics [3:272075] 15:15:31.519 {
Vary Validation: (null)
Evaluation: PASS
Request: https://content.dropboxapi.com/<redacted>
VaryHeader: Dropbox-API-Arg, Authorization
} [3:272075]
default 15:15:31.519387-0700 Joplin CFNetwork Diagnostics [3:272074] 15:15:31.519 {
LoaderWhatToDo: (null)
Request: https://content.dropboxapi.com/<redacted>
CachePolicy: 0
WhatToDo: originload
CreateToNow: 0.00093s
} [3:272074]
default 15:15:31.519254-0700 Joplin CFNetwork Diagnostics [3:272073] 15:15:31.519 {
Vary Validation: (null)
Evaluation: PASS
Request: https://content.dropboxapi.com/<redacted>
VaryHeader: Dropbox-API-Arg, Authorization
} [3:272073]
default 15:15:14.050982-0700 Joplin Task <redacted-task-id>.<10> resuming, timeouts(0.0, 604800.0) QOS(0x19) Voucher (null)
default 15:15:14.050704-0700 Joplin CFNetwork Diagnostics [3:271985] 15:15:14.050 {
HTTPCookieStorage::copyCookiesForURL: <CFHTTPCookieStorage 0xredacted [0xredacted]>
Request URL: https://content.dropboxapi.com/<redacted>
MainDocument URL: null
} [3:271985]
error 15:15:10.042740-0700 Joplin Task <C49036A5-617D-4742-B3E3-58641BD95148>.<9> finished with error [-1005] Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=57, NSUnderlyingError=0x600000c78060 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0xredacted [0xredacted]>{length = 16, capacity = 16, bytes = 0xredacted}, _kCFStreamErrorCodeKey=57, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <redacted-task-id>.<9>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <redacted-task-id>.<9>"
), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://content.dropboxapi.com/2/files/download, NSErrorFailingURLKey=https://content.dropboxapi.com/2/files/download, _kCFStreamErrorDomainKey=1}
default 15:15:10.042500-0700 Joplin Task <redacted-task-id>.<9> summary for task failure {transaction_duration_ms=442, response_status=200, connection=8, reused=1, reused_after_ms=9620, request_start_ms=1, request_duration_ms=0, response_start_ms=440, response_duration_ms=0, request_bytes=179, response_bytes=96, cache_hit=true}
default 15:15:10.042383-0700 Joplin CFNetwork Diagnostics [3:271970] 15:15:10.042 {
Did Fail: (null)
Loader: request GET https://content.dropboxapi.com/<redacted>
Error: Error Domain=kCFErrorDomainCFNetwork Code=-1005 UserInfo={NSErrorPeerAddressKey=<private>, _kCFStreamErrorCodeKey=57, _kCFStreamErrorDomainKey=1}
init to origin load: 0.000844955s
total time: 0.442753s
total bytes: 0
} [3:271970]
Many of the `<redacted>` sections above were removed by XCode or iOS.
Additionally, I notice that the above log includes "cache_hit=true".
- Greg-DB
Yes, unfortunately it's still not very clear with this output.
I do see that it has "response_status=200", which doesn't seem to match the other output we've seen (where there doesn't seem to be a response), but that may be because as you noted it says "cache_hit=true", so perhaps it's actually referring to a cached response from a previous call. That may imply an issue with how the platform's caching works. I'm not aware of a mistake with how the Dropbox API servers currently handle any caching headers, but if there seems to be an issue with that please let me know what exactly seems to cause an issue for your platform and I can raise that with the team.
Also, I notice there are some other error codes "_kCFStreamErrorCodeKey=57, _kCFStreamErrorDomainKey=1". I'm not familiar with those, and we can't provide support for the platform/network client itself as it's not made by Dropbox, but do you know what those particular codes may indicate?
> Also, I notice there are some other error codes "_kCFStreamErrorCodeKey=57, _kCFStreamErrorDomainKey=1". I'm not familiar with those, and we can't provide support for the platform/network client itself as it's not made by Dropbox, but do you know what those particular codes may indicate?
I don't know what the `_kCF...` error codes mean and didn't find references to these particular error codes with a web search or in the Apple documentation.
> I do see that it has "response_status=200", which doesn't seem to match the other output we've seen (where there doesn't seem to be a response), but that may be because as you noted it says "cache_hit=true", so perhaps it's actually referring to a cached response from a previous call.It's strange that this is a cache hit — the original response contains `Cache-Control: no-cache`. It would be interesting to compare the current headers with those from a few weeks ago to see if this, or other cache-related headers changed.
We merged a workaround that, on request failure, sends a request for a different file before retrying the original request. Even though failure doesn't occur for most `files/download` GET requests, the extra API requests required by this workaround aren't ideal.Forcing iOS to avoid the cache may be a better solution. As such, I've also tried:
• Passing `Cache-Control: no-cache` as an additional request header. (Doesn't work -- same "network request failed" error).
• Adding a new header and adding/referencing it in the `Vary` header (see this StackOverflow discussion). (Doesn't work -- same "network request failed" error).• Retrying with `?` appended to the Dropbox `files/download` URL on failure. (Doesn't work -- same "network request failed" error).
• Retrying with `?retry` appended to the Dropbox `files/download` URL on failure. This results in `Error (400): Error in URL parameters: Bad query field: 'retry'`.
- Greg-DB
I found an old sample of a /2/files/download call from November in my records. The request didn't have the same browser/CORS headers, so it's not an exact comparison, but for reference the response did have "Cache-Control: no-cache".
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
