GET request to /files/download fails with "The network connection was lost"

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".

Thank you for checking!

The 200 OK response attached in a previous message has "Vary: Dropbox-API-Arg, Authorization". Based on MDN, the Vary header is related to caching and content-negotiation. Does the November response have a similar Vary header?

---
Edit:
The XCode network logs contain:

Vary Validation: (null)
     Evaluation: PASS
        Request: https://content.dropboxapi.com/<redacted>
     VaryHeader: Dropbox-API-Arg, Authorization
} [3:272075]

According to this article, the Vary header is often used to validate a cache record (to determine whether that record can be used or if the request should be treated as a cache miss).

Based on this, one possibility is that the original `Cache-Control: no-cache` causes the response to not be cached (or incorrectly cached). The next request checks the last request's "Dropbox-API-Arg" and "Authorization" because of the "Vary" header. In this case, they're the same, so the system treats this as a cache hit. However, the previous response isn't correctly cached, causing an error. Note that this is just a guess. It should be possible to test this with a local webserver, however.

Edit 2: "no-cache" means "revalidate before using the cache" while "no-store" means "don't store responses in the cache". Based on this, revalidating is expected.

Based on this, I've tested with setting the fetch `cache` to `no-store` to disable caching,

await fetch(
  "https://content.dropboxapi.com/2/files/download",
  {
    "headers": {
      "Dropbox-API-Arg": "{\"path\":\"/info.json\"}",
      "Authorization": "Bearer TOKEN_HERE",
      "Content-Type": "application/octet-stream"
    },
    "method": "GET",
    "cache": "no-store"
  }
)

I'm currently in the process of testing this.

Unfortunately, "cache": "no-store" doesn't seem to help.

Based on a suggestion received elsewhere, I've also tried adding an If-None-Match set to a random value:

await fetch(
  "https://content.dropboxapi.com/2/files/download",
  {
    "headers": {
      "Dropbox-API-Arg": "{\"path\":\"/info.json\"}",
      "Authorization": "Bearer TOKEN_HERE",
      "Content-Type": "application/octet-stream",
      "If-None-Match": "JoplinIgnore-" + (Math.floor(Math.random() * 100000)),
    },
    "method": "GET"
  }
)

 Our source code already had a similar workaround for a different sync provider with the comment,

> On iOS, the network lib appends a If-None-Match header to PROPFIND calls, which is kind of correct because the call is idempotent and thus could be cached. According to RFC-7232 though only GET and HEAD should have this header for caching purposes. It makes no mention of PROPFIND.
> [... additional commenting ...]

This is a GET request and not a PROPFIND request. However, I suspect that passing a random `If-None-Match` overrides the iOS network library's default and forces Dropbox to return a 200 OK response (rather than a 304 Not Modified, which I think may have been Dropbox's response when the issue occurred).

I'm in the process of testing this. So far, however, it seems to work. This is the pull request with the relevant change.

Thank you for helping me debug this!

Thanks for following up and sharing this! I'm glad to hear you were able to work that out.

I just faced the same error in a native iOS app, can confirm this is cache-related.

The app uses Apple's own URLRequest, no wrappers. When sending POST requests for the same file to "2/files/download" endpoint:

• First request works fine and returns the file
• The second request depends on urlRequest.cachePolicy:
  • Fails with -1005 if cache policy is not set or allows caching
  • Works out fine if set to .reloadIgnoringLocalCacheData

personalizedrefrigerator , thank you for the hint in the right direction!