Child Item

Downloading part of a file via /get_temporary_link with Range header returns incorrect content-type

When downloading a specific part of a file using the link received via a /get_temporary_link call and the HTTP header Range: bytes=..., the content-type application/grpc is sent instead of the actual content-type of the file.

Request Headers:

GET https://uc383828c22b...3d5ecbc28.dl.dropboxusercontent.com/cd/0/get/B61A....17HuE3Lr3UI4EEpPY/file
range:bytes=0-

Expected Response Headers:

HTTP/1.1 206 Partial Content
---
accept-ranges:bytes
Content-Length:26397831
Content-Range:bytes 0-26397830/26397831
content-type:video/mp4

Actual Response Headers:

HTTP/1.1 206 Partial Content
---
accept-ranges:bytes
Content-Length:26397831
Content-Range:bytes 0-26397830/26397831
content-type:application/grpc

So in this example (actually downloading the full file, but with the Range header), the video file is downloaded with a content-type of application/grpc rather than video/mp4.

This causes problems when (for example) you want to display a video file in an HTML 5 player using the link received from the /get_temporary_link call. The HTML 5 player buffers the video file and loads the data in chunks. However, due to the incorrect content type, the browser will not accept the data as video content and will not be able to play it.

I've just noticed this problem, and I didn't have any problems with it before. So I think this problem has been introduced recently?

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

This should be fixed now. Please let us know if you're still seeing any issues.

All comments

ncw

Rclone users have reported a similar problem when using anything with `Range:` requests.

There is a long thread here https://forum.rclone.org/t/failed-to-open-source-not-an-encrypted-file-bad-magic-string/37790

But my summary is that Range: requests are not working properly. They appear to produce files which have an extra bit of HTTP header in them such as this (from the link above)

I noticed "application/octet-stream" inside my all files header.
Because of that, my applications do not recigionize files as valid.

0000000 000 000 002 000 042 012 236 200 010 012 030 141 160 160 154 151
         \0  \0 002  \0   "  \n 236 200  \b  \n 030   a   p   p   l   i
0000020 143 141 164 151 157 156 057 157 143 164 145 164 055 163 164 162
          c   a   t   i   o   n   /   o   c   t   e   t   -   s   t   r
0000040 145 141 155 022 200 200 010 120 162 157 157 146 040 157 146 040
          e   a   m 022 200 200  \b

This looks like a Dropbox bug to me.

ncw

Here is a failing request and response

I managed to reproduce this with a small file file.txt contents shello and using

rclone cat --offset 3 dropbox:file.txt -vv --dump bodies

This made this request

2023/04/25 11:20:46 DEBUG : HTTP REQUEST (req 0xc0009fec00)
2023/04/25 11:20:46 DEBUG : POST /2/files/download HTTP/1.1
Host: content.dropboxapi.com
User-Agent: rclone/v1.63.0-beta.6980.470db6bcd
Content-Length: 0
Authorization: XXXX
Content-Type: application/octet-stream
Dropbox-Api-Arg: {"path":"id:qqS0afUHwS0AAAAAAA6Nig"}
Range: bytes=3-6

And this response which appears to have muddled up the body with the header

2023/04/25 11:20:47 DEBUG : HTTP RESPONSE (req 0xc0009fec00)
2023/04/25 11:20:47 Unsolicited response received on idle HTTP channel starting with "\"\n \n\x18application/octet-stream\x12\x04llo\n"; err=<nil>
2023/04/25 11:20:47 DEBUG : HTTP/1.1 206 Partial Content
Content-Length: 4
Accept-Encoding: identity,gzip
Accept-Ranges: bytes
Content-Range: bytes 3-6/7
Content-Security-Policy: sandbox allow-forms allow-scripts
Content-Type: application/grpc
Date: Tue, 25 Apr 2023 10:20:46 GMT
Dropbox-Api-Result: {"name": "file.txt", "path_lower": "/file.txt", "path_display": "/file.txt", "id": "id:qqS0afUHwS0AAAAAAA6Nig", "client_modified": "2022-11-09T12:59:37Z", "server_modified": "2022-11-09T12:59:41Z", "rev": "5ed093ae1400f082af73a", "size": 7, "is_downloadable": true, "content_hash": "483068e5287bde73b67923dae8c200d461d80997108030841a082e628489993b"}
Etag: W/"5ed093ae1400f082af73a"
Original-Content-Length: 4
Server: envoy
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Dropbox-Request-Id: e186d6db20684aee82e1123611632a3a
X-Dropbox-Response-Origin: far_remote
X-Robots-Tag: noindex, nofollow, noimageindex

Greg-DB

Thanks for the report! We're looking into it. I'll follow up here once I have an update on this.

WoisWoi

Hi,

Is it possible to have an ETA, please ?

Greg-DB

@WoisWoi I don't have an ETA on a fix to share right now. I'll follow up here once I have any news.

b3nZol

Issue reported hours ago, Dropbox confirmed that there is an issue, status.dropbox.com still says "All Systems Operational". Thats poor to be honest.

Greg-DB

@b3nZol Thanks for the feedback! I'll share this with the team.

aniel3000

agree

needo

Any updates? Been a few hours now. And this is a pretty major outage.

Greg-DB

@needo The team is currently working on resolving this issue. We'll follow up once we have an update on this.

ak2k

Hi @Greg-DB, Corruption of all read range-requests is a major issue and affects many Dropbox users. Could you please confirm the priority assigned to this internally at Dropbox?

WoisWoi

I think he just did.

Greg-DB

@ak2k The team is actively working to resolve this issue as soon as possible.

aniel3000

thank u for letting us know

ak2k

Thank you. I also appreciate the acknowledgement on status.dropbox.com: https://status.dropbox.com/incidents/gp968mjw7t4d

rylincoln

Didn't see anyone else mention this yet so.

This happens even when not requesting part of a file; simply trying to access a `get_temporary_link` response directly returns the wrong content-type.

Broke the video viewing part of our mapping application.

Greg-DB

@rylincoln In my testing, this issue is not affecting requests not specifying "Range" to the temporary links returned by /2/files/get_temporary_link; I am not seeing the incorrect "Content-Type" in that case. Note that some media/video players do automatically set "Range" themselves though. If you are seeing otherwise however, please share a sample request/response so we can check on it.

De L.1

@rylincoln That isn't something I can reproduce. Requesting the links returned by /get_temporary_link itself will just give me the correct Content-Type, a 200 HTTP response code and it will download without problems.

(edit) Ah, I see Greg already responded to this...

rylincoln

De L.1

I simply tested by generating a temporary link, copying that link directly into my browser URL and inspecting the request.

and i got back content-type: application/grpc

¯\_(ツ)_/¯

rylincoln

But i think Dropbox fixed the issue, cuz now i'm getting back correct content-type and our application plays videos as expected.

Greg-DB

@rylincoln Thanks for the note. I wasn't able to reproduce that exact behavior, but depending on how your device/browser was trying to play the video, it may have been automatically sending 'Range'. In any case, I'm glad to hear you're seeing it working again. We have begun to roll out a fix. Please note it will take some to fully deploy it.

TaiT

It already works for me. Thank you very much Dropbox team

For future API updates, don't forget to make Rclone compatible. We are a great community.

I know that third-party applications are not a priority. But I wouldn't like to leave this team after 4 years with you.

A hug

WoisWoi

Same for me (possibly with degraded performance) and I totally agree with you 🙂

Pyker

It works for me sometimes, I presume that it's still rolling out.

star_fox

i still get errors

2023/04/25 20:49:03 ERROR : MOVIE.mkv: ReadFileHandle.Read error: low level retry 5/10: failed to authenticate decrypted block - bad password?
2023/04/25 20:49:05 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:07 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:08 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:08 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:10 Unsolicited response received on idle HTTP channel starting with "m\x12 RCLONE\x00\x00\xe8*Z\x9eT\x1cG\xd4\xf8[\x96e\x9e\xdd\xef\x145\x97\xb9\xa0H\xf2\xe6J"; err=<nil>
2023/04/25 20:49:10 ERROR : MOVIE.mkv: ReadFileHandle.Read error: low level retry 1/10: not an encrypted file - bad magic string
2023/04/25 20:49:12 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:13 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:15 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:16 ERROR : IO error: not an encrypted file - bad magic string
2023/04/25 20:49:17 ERROR : IO error: not an encrypted file - bad magic string

Greg-DB

The fix is rolling out and is not out fully everywhere yet.

star_fox

now i get no errors anymore

thanks!

Greg-DB

This should be fixed now. Please let us know if you're still seeing any issues.

Pyker

Thank you! It's working great now.