cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: application/binary type returned for media files

application/binary type returned for media files

abiluck
Explorer | Level 4
Go to solution

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?

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

We've reverted to the previous behavior for newly returned links. I can't guarantee what the exact behavior will be long-term, but I'll follow up once I have an update on that.

View solution in original post

31 Replies 31

Greg-DB
Dropbox Staff
Go to solution

Thanks for the report. We'll look into it.

Greg-DB
Dropbox Staff
Go to solution

We've reverted to the previous behavior for newly returned links. I can't guarantee what the exact behavior will be long-term, but I'll follow up once I have an update on that.

abiluck
Explorer | Level 4
Go to solution

Awesome! Thank you for prompt response and resolution.

abiluck
Explorer | Level 4
Go to solution

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.

Greg-DB
Dropbox Staff
Go to solution

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.

abiluck
Explorer | Level 4
Go to solution

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. 

abiluck
Explorer | Level 4
Go to solution

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.

Greg-DB
Dropbox Staff
Go to solution

I don't have an update on this yet. I'll check in with the team and follow up here once I have any news.

Greg-DB
Dropbox Staff
Go to solution

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?

Need more support?