Child Item

application/binary type returned for media files

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?

Find more posts tagged with

API

Abuse

Accepted answers

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.

All comments

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

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.

Awesome! Thank you for prompt response and resolution.

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.

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.

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?

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.

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?

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?

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.

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?

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.

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?

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.)

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

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

@abiluck No, unfortunately I can't make any promises right now. I'll follow up when I have any news on this from the team.

@Greg-DB it is impacting users and I am getting lots of support tickets on this matter. Appreciate if the team could look into this asap.

@abiluck Thanks for the note. This is still open with the team. I'll let you know as soon as we have an update on that.

I'm in the same boat, got clients crawling all over me. They have all sorts of VR content and they stream it for some reason.

@SlashAndBurn Thanks for the note. I'll check in with the team on this.

This should be working again now. Please try again and let us know if you're still seeing any issues.

@abiluck It looks like we never actually returned the specific type for .m4b in particular anyway, but if that's important let me know and I'll ask the team to add that.

It is working now! Thank you for fixing this.

As for m4b, it should have "audio/mp4" content-type

@abiluck Thanks for confirming! I'll ask the team if we can add support for .m4b as well.

Tried to play a mp4 file and it is playing again, nice!

Hi @Greg-DB, would it be possible to fix content-type for m4b format?

@abiluck The request for that is still open with the team, but I don't have any news on that right now. I'll follow up here with any update on that.

Featured Links