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?

31 Replies 31

abiluck
Explorer | Level 4
Go to solution

As for the .m4b the correct content-type should be "audio/mp4", because m4b container format is very similar to m4a.

 

The larger issue I have is the one I described earlier in the thread, namely that urls obtained with getTemporaryLink can no longer be played with standard iOS AVPlayer component. I wasn't able to identify the root cause for that. The content-type for other media formats like mp3 and m4a is correct, but may be something else has changed in the server response on your end. I was hoping you will be able to identify the changes on the backend that happened in that timeframe.

Greg-DB
Dropbox Staff
Go to solution

Ok, thanks. So, as it stands right now, even .m4a and .mp3 files aren't working for you. (I was previously under the impression the first fix was working for those from your earlier responses.)

 

Anyway, we unfortunately can't provide support for AVPlayer, since that's not made by Dropbox. We have recently updated the implementation of the links returned by get_temporary_link and we'll be happy to see if we can further update it to accommodate this use case, but we'd need some more specific information as to what behavior is needed. Perhaps you can get some support or documentation from Apple to determine what the requirements are to avoid this "This media format is not supported" error?

abiluck
Explorer | Level 4
Go to solution

Correct, none of the media formats can be played right now. Unfortunately, there isn't any description about this error in Apple documentation. Last time it was caused by wrong content-type, but now content-type is correct for mp3, m4a, mp4 so there must be something else. Is it possible to identify what has changed in http response headers in October when requesting the file with get_temporary_link?

Greg-DB
Dropbox Staff
Go to solution

I'll see if we can track down what may have changed there, but the Dropbox API spec doesn't document or guarantee these particular aspects of these links, so I can't make any promises unfortunately.

abiluck
Explorer | Level 4
Go to solution

Hi, after numerous experiments I found out iOS AVPlayer does not like "X-Content-Security-Policy" field in the response header. It seems like this field has been deprecated and replaced with "Content-Security-Policy" which you already return in response. Is it something that can be fixed?

Greg-DB
Dropbox Staff
Go to solution

Thanks for sharing this. Can you also share any documentation or output showing that's the issue though, for our reference? I ask because we're still looking into this, but we believe we've found a behavior on our side that, in some cases, would affect the content type that the client is using.

 

I'll follow up with any updates on that, but in the meantime it looks like you can also work around this like this:

 

 

let asset = AVURLAsset(url: url, options:["AVURLAssetOutOfBandMIMETypeKey": "audio/mpeg"])

 

 

You'd need to come up with a way to dynamically determine the correct MIME type for the file though (e.g., mapping from file extension to MIME type), in place of the "audio/mpeg" here.

abiluck
Explorer | Level 4
Go to solution

I used a sample app with reverse proxy server on the device. When the file is requested from Dropbox server, the response headers can be altered and then passed to AVPlayer. This way I have determined that without ""X-Content-Security-Policy" AVPlayer is able to play the file.

Would source code be helpful?

Greg-DB
Dropbox Staff
Go to solution

I see, thanks. I believe in that kind of setup, the reverse proxy would actually obscure the issue we found, since it's making the request on behalf of the client, instead of the client doing it itself. (And according to a sample I saved from October 1, we were already previously sending 'X-Content-Security-Policy' anyway.)

abiluck
Explorer | Level 4
Go to solution

Thank you for looking into this. If you apply a fix, please let me know so I can try.

abiluck
Explorer | Level 4
Go to solution

Hi @Greg-DB , do you know when this will be fixed? 

Need more support?