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

[De L.1]

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?

[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

¯\_(ツ)_/¯