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
file downloads have wrong content-type header
Hello,
I'm testing out dropbox v2 files api. when I call "POST https://content.dropboxapi.com/2/files/download" API, the downloaded file seems to be always returned with the content-type header set to application/octet-stream. Am I doing something wrong or is this to be expected?
As far as I can tell the contents of file file are OK, it's just the header that's wrong
Receiving a 'Content-Type: application/octet-stream' response header on a successful /2/files/download call is the expected behavior.
The Dropbox API doesn't return specific mime types for files, but you can get the file extension from the file name and keep your own file extension to mime type mapping as desired.
- Greg-DB
Dropbox Staff
Receiving a 'Content-Type: application/octet-stream' response header on a successful /2/files/download call is the expected behavior.
The Dropbox API doesn't return specific mime types for files, but you can get the file extension from the file name and keep your own file extension to mime type mapping as desired.
Thanks - it seems a bit strange that a web-based file transfer API doesn't support content types but that's their decision I guess.
For unrelated reasons I ended up using "files/get_temporary_link" instead of "files/download" and strangely enough when you download the file from the temporary link, the content-type appears correctly. I guess this might be another workaround for someone who doesn't want to map the mime types manually
Thanks for this actual solution. Using "files/get_temporary_link" required an additional API call to deliver the file, but is preferrable IMO to guessing with the file extension.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
