0 votes
by (1.9k points)


When using HTTPS, the server's response comes with ContentType: Application/grpc, and the data becomes strange.

If you have such grpc data, please let me know if you know how to handle it.

First of all, the first part of the data is attached with the following information.

0x00, 0x00, 0x02, 0x00, 0x22, 0x0A, 0x9E, 0x80, 0x08, 0x0A, 0x18, 0x61, 0x70, 0x70, 0x6C, 0x69, 0x63, 0x61, 0x74, 0x69, 0x6F, 0x6F, 0x6F, 0x6F, 0x6F 0x63; 0x74, 0x65, 0x74, 0x2D, 0x73, 0x74, 0x72, 0x65, 0x61, 0x6D, 0x12, 0x80, 0x80, 0x08

It seems to have the letters "application/octet-stream" and other information.

This is the first time I've seen such a case and I don't know how to start.
Please help me.

Headers requested:
GET https://content.dropboxapi.com/2/files/download HTTP/1.1
Host: content.dropboxapi.com
Connection: keep-alive
Authorization: Bearer ...
Dropbox-API-Arg: {"path":"id:"}
Range: bytes=0-1048575
User-Agent: RaiDrive/2023.2.39.0

Response header: The total received body size is 1048849.
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Disposition: attachment; filename=unspecified
Content-Range: bytes 0-1048575/6080306
Content-Security-Policy: sandbox
Content-Security-Policy: sandbox allow-forms allow-scripts
Etag: W/"5fa254c2c13e12112719d"
Original-Content-Length: 1048576
Vary: Dropbox-API-Arg, Authorization
X-Content-Security-Policy: sandbox
X-Content-Type-Options: nosniff
X-Webkit-Csp: sandbox
Content-Type: application/grpc
Accept-Encoding: identity,gzip
Date: Tue, 25 Apr 2023 09:59:58 GMT
Server: envoy
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Robots-Tag: noindex, nofollow, noimageindex
Content-Length: 1048576
X-Dropbox-Response-Origin: far_remote
X-Dropbox-Request-Id: 39bed946920f47beb96865cf85924cfa

Applies to: Rebex HTTPS

1 Answer

+1 vote
by (147k points)
selected by
Best answer

What are you actually trying to achieve?

The resource at https://content.dropboxapi.com/2/files/download is not a file, so there is no point trying to download it. It's part of Dropbox API. For details on how to use Dropbox API's RPC endpoints like this one, see the relevant Dropbox API documentation.

by (1.9k points)
Thank you.

This seems to be a DropBox issue.
ContentLength in particular seems to be the problem.
ContentLength is smaller than the actual data, causing the problem.
It seems that there is a problem related to the envoy server that grpc bridges.

The actual download is downloaded according to this information: Dropbox-API-Arg: {"path":"id:"}
Full download works very well.
This is a situation where the problem occurs during partial download, and it seems that all DropBox users are experiencing the problem.
by (147k points)
It looks like you might be right. I checked the Dropbox API documentation and it looks like the response for https://content.dropboxapi.com/2/files/download endpoint is actually supposed to contain file data:

"Content-download endpoints ... As with content-upload endpoints, arguments are passed in the Dropbox-API-Arg request header or arg URL parameter. The response body contains file content, so the result will appear as JSON in the Dropbox-API-Result response header. These endpoints are also on the content.dropboxapi.com domain."

But if that's actually the case, then it makes no sense for Dropbox to return the "application/grpc" response. And wrong ContentLength just makes things worse. It looks like the content length was simply calculated from "Range: bytes=0-1048575" supplied by the client.

Interestingly, according to this forum, the content-type is supposed to be application/octet-stream:

So unfortunately, I'm not quite sure what's going on.

By the way, the data you received - 0x61, 0x70, 0x70, 0x6C, 0x69, 0x63, 0x61, 0x74, 0x69, 0x6F, 0x6F, 0x6F, 0x6F, 0x6F 0x63; 0x74, 0x65, 0x74, 0x2D, 0x73, 0x74, 0x72, 0x65, 0x61, 0x6D - translates to "applicatioooooctet-stream", but perhaps that's just a copy&paste mistake.
by (1.9k points)
thanks for the answer
DropBox has fixed this issue.
everything works fine.