Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Hi, I am using gettemporarylink API to obtain url to the file that can be later played. That url when requested itself, returns wrong Content-Type header for media files. For example audio file with m4a extension now has Content-Type response header set to “application/binary” instead of “audio/mp4” or “audio/mpeg”. Such behaviour has started in the last 24 hours and breaks our entire workflow. No changes were made on our side and it used to work before. Could you please look into this?
Hi, looks like the problem is back although it is a bit different now.
1. When accessing .m4b file with temp link I am getting content-type = "application/octet-stream"
2. Files > 100Mb cannot be played using the temp url. Error: Maximum response size reached
The problem started around Oct 14-15. Please have a look.
1. Thanks, we'll check on this.
2. The "Maximum response size reached" error doesn't appear to be coming from Dropbox itself. I also just tried and I was able to successfully access a file larger than 100 MB via a temporary link retrieved by get_temporary_link, so it looks like this is a client-side issue. You'll need to troubleshoot whatever client you're using to attempt to play that.
Thank you for looking into this. You are right about #2, it was an error from Postman, sorry about that.
I discovered #1 while investigating the bigger issue, that we are currently experiencing. We use default AVPlayer iOS component to play media in the iOS app. It was working fine for years until recently. Now it refuses to play any media from Dropbox, returns an error "
This media format is not supported". This error is quite generic and usually happens when AVPlayer can't play the file for whatever reason. In order to isolate the problem, I tried very basic sample app with AVPlayer, hardcoded url and play button and it refuses to play the file from Dropbox provided the temp url. I can provide a link to the GitHub sample project if that would be of any help.
It was working fine after you reverted the changes to content-type in the generated link. This time the content-type is correct but the AVPlayer still refuses to play any audio file. This started on Oct 14-15.
Hi, is there any update to this problem? It's been impacting many users and I am trying to determine the reason as there were no changes on the client side and it suddenly stopped working. If you need any additional information, please let me know.
We're looking into this, and for reference, we are still now returning a "Content-Type" of "audio/mp4" for .m4a files, and I can confirm we are currently returning "application/octet-stream" for .m4b files. From what we can tell though, we did not previously return a more specific "Content-Type" like "audio/mp4" for .m4b.
Can you confirm if you are currently seeing an issue only for .m4b files, or for .m4a files as well?
Either way, can you more specifically identify what behavior you would need to get this working for your use case?
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!