It seems that perhaps the mime type checking is a bit too strict for my
needs. I'm uploading a valid file extension with a valid mime type, but
it's being rejected. I can't check my /etc/mime.types at the moment but the
audio/mpeg mpga mpega mp2 mp3 m4a
meaning that an m4a file with any mime type other than audio/mpeg will be
rejected, which is probably not good because audio/m4a is the most correct,
and audio/x-m4a should be similarly valid.
I'm not really sure what to do here as a client developer because it seems
that many servers will be running this extension and rejecting all sorts of
valid mime types because it appears people disagree about what mime types
correspond to what file extensions. Adding client logic to retry with
random mime types seems totally insane.
I think that we should (by default) relax the strictness when receiving an
unexpected mime type and just trust the clients to do the right thing, and
let server operators opt-in to more strict behavior if needed.
Thoughts? I'll make and submit a patch if I don't hear any objections.
<iq type="get" to="xmpp.example.com"
<iq xmlns="jabber:client" id="61528B53-923F-4687-B01B-EA4978E69920"
type="error" to="simula...@example.com/chatsecure49016" from="
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">MIME type does not match file
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.