Bug #100138
closed
audio wav with mime type audio/x-wav is not recognized as audio file
Added by Alexander Bohn over 1 year ago.
Updated 5 months ago.
Description
audio/wav -> HTML Audio Tag is correctly rendered
audio/x-wav -> Img Tag is rendered
after changing the sys_file/myme_type from audio/x-wav to audio/wav it is working.
- Status changed from New to Under Review
changed it in the AudioTagRenderer to protected $possibleMimeTypes = ['audio/mpeg', 'audio/wav', 'audio/x-wav', 'audio/ogg'];
maybe you wanna review the change in gerrit?
Thank you for the additional information which states "you should likely still support it".
As it is needed, it is super easy to implement, it has no side effects and it is recommend it to support it - we should add the mime type to the cms.
Would you mind answering my last question?
Question is, where does this mime-type come from?
What are you doing such that the system identifies a file as audio/x-wav?
Any outdated mime-type detection going on?
I'd like to understand how the problem is rooted.
Question is, where does this mime-type come from?
That´s what the customer told me:
I also looked into where the mime-type comes from (different browsers on Mac and Windows), but couldn't figure out why it's set to x-wav. According to the StackOverflow article, Chrome (or Chromium) and Firefox either set it themselves or the operating system sets it when uploading (I also found x-wav in the Windows registry). I haven't had time to try Linux yet.
Thanks. my question was a bit misleading. The mimetype is usually determined by the server of course. I meant: Which library on the server does the mimetype detection?
I assume this is simply outdated there. I understand, though, that this might not be changeable any time soon.
Note: If the mime-type sent by the client would be trusted, this would be very insecure.
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF