You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
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?
This should be fixed now. Please let us know if you're still seeing any issues.
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.
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
Dropbox Staff
Thanks for the report! We're looking into it. I'll follow up here once I have an update on this.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
