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
here suggests:

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=""

<iq xmlns="jabber:client" id="61528B53-923F-4687-B01B-EA4978E69920"
type="error" to="" from=""><error type="modify"><bad-request
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 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to