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

Hi,

The Joplin note taking app uses Dropbox's HTTP API  to upload and download files. Since a few days ago, some of our its requests are failing with "The network connection was lost".

The failing request downloads files from Dropbox using a GET request to content.dropboxapi.com/2/files/download:

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

Sometimes, the above fetch does work. However, I can reproduce the failure consistently by sending the above request twice, but only in some environments:
 - Running code from the Safari development tools, inspecting a WebView embedded in Joplin.
 - Running code from the Chrome development tools, connected to React Native Hermes.

I can't reproduce this when using the same code in a NodeJS REPL or the Firefox JavaScript console.

The examples in the Dropbox documentation send POST rather than GET requests to files/download. Switching to a POST request does seem to fix the issue on Android. However, it still fails on iOS.

Another post on this forum suggests that fetch on iOS doesn't support sending POST requests with an empty body. Dropbox doesn't seem to allow a non-empty body for this request.

Is this forum the correct place to be asking for help with this issue? Is there a way to continue using a GET request to /files/download to download files?

Notes:
- The original version of this post was marked as spam, perhaps due to links to Joplin's source code and issue tracker. These links have been removed and can be provided on request.

- Joplin uses React Native 0.71. The issue still happens after upgrading to React Native 0.73.8.

I have the opposite issue!
I also have a ReactNative app, and In the last few days (since April 30), I have seen this error occur only for my iOS users and only on the https://content.dropboxapi.com/2/files/download… endpoint.

Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost."

But I use POST for it. Once I change it to GET it seems to fix the issue on iOS.

WDYT?

While we can't offer insight on the client platforms/libraries in particular, this is the right place for help with the Dropbox API itself.

For reference, the Dropbox does use POST for all API calls by default, but "content-download" style endpoints, such as /2/files/download, do additionally support GET. And it's correct that the endpoint does not support POST requests with a non-empty body.

I just tried it out, and confirmed that the API is still allowing both GET and POST for this endpoint in my testing:

curl -v -X POST https://content.dropboxapi.com/2/files/download \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Dropbox-API-Arg: {\"path\":\"/test.txt\"}" \
    --header "Content-Type: application/octet-stream"

> POST /2/files/download HTTP/2
> Host: content.dropboxapi.com
> User-Agent: curl/8.4.0
> Accept: */*
> Authorization: Bearer <ACCESS_TOKEN>
> Dropbox-API-Arg: {"path":"/test.txt"}
> Content-Type: application/octet-stream
>
< HTTP/2 200
< content-type: application/octet-stream
< accept-ranges: bytes
< cache-control: no-cache
< dropbox-api-result: {"name": "test.txt", "path_lower": "/test.txt", "path_display": "/test.txt", "id": "id:25N5ksooX-sAAAAAAAQYrQ", "client_modified": "2024-03-11T15:24:40Z", "server_modified": "2024-03-11T15:24:40Z", "rev": "6136423edf446021eccc7", "size": 27, "is_downloadable": true, "content_hash": "cceac37da5288a6b6716737310c14305c9b16a6e0ff0abce4a306c3de3a59f75"}
< etag: W/"6136423edf446021eccc7"
< original-content-length: 27
< x-server-response-time: 375
< date: Mon, 06 May 2024 15:09:05 GMT
< server: envoy
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-robots-tag: noindex, nofollow, noimageindex
< content-length: 27
< x-dropbox-response-origin: far_remote
< x-dropbox-request-id: d0eb597d801d4203819d86c9b65b42a1
<
* Connection #0 to host content.dropboxapi.com left intact
This is the test file data.

curl -v -X GET https://content.dropboxapi.com/2/files/download \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Dropbox-API-Arg: {\"path\":\"/test.txt\"}" \
    --header "Content-Type: application/octet-stream"

> GET /2/files/download HTTP/2
> Host: content.dropboxapi.com
> User-Agent: curl/8.4.0
> Accept: */*
> Authorization: Bearer <ACCESS_TOKEN>
> Dropbox-API-Arg: {"path":"/test.txt"}
> Content-Type: application/octet-stream
>
< HTTP/2 200
< content-type: application/octet-stream
< accept-ranges: bytes
< cache-control: no-cache
< content-disposition: attachment; filename=unspecified
< content-security-policy: sandbox
< dropbox-api-result: {"name": "test.txt", "path_lower": "/test.txt", "path_display": "/test.txt", "id": "id:25N5ksooX-sAAAAAAAQYrQ", "client_modified": "2024-03-11T15:24:40Z", "server_modified": "2024-03-11T15:24:40Z", "rev": "6136423edf446021eccc7", "size": 27, "is_downloadable": true, "content_hash": "cceac37da5288a6b6716737310c14305c9b16a6e0ff0abce4a306c3de3a59f75"}
< etag: W/"6136423edf446021eccc7"
< original-content-length: 27
< vary: Dropbox-API-Arg, Authorization
< x-content-security-policy: sandbox
< x-content-type-options: nosniff
< x-server-response-time: 340
< x-webkit-csp: sandbox
< date: Mon, 06 May 2024 15:09:29 GMT
< server: envoy
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-robots-tag: noindex, nofollow, noimageindex
< content-length: 27
< x-dropbox-response-origin: far_remote
< x-dropbox-request-id: 1eaaff94c0f84f2f91cf96059913ee87
<
* Connection #0 to host content.dropboxapi.com left intact
This is the test file data.

I included the "Content-Type" request header to match your example, but it's not actually required for this. Also, I tried the GET request several times in a row without issue.

So, it does sound like this issue is environment-specific. We'd be happy to look into it further on our side to see if there's something we can do about it from the Dropbox server side, but it's unclear what the issue is exactly so far. Is there a way you could enable some more verbose output (similar to -v for curl above) to gather more information about how exactly the request is failing in the affected environments?