Hey, Starting a reply, then forgetting about it for a month is a thing I apparently do, sorry about that.
On Wed, Jun 14, 2017 at 02:57:06PM -0700, Chris Ballinger wrote: > 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 > default > https://www.apt-browse.org/browse/debian/jessie/main/all/mime-support/3.58/file/etc/mime.types > 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="xmpp.example.com" > id="61528B53-923F-4687-B01B-EA4978E69920"><request > xmlns="urn:xmpp:http:upload"><filename>9F529FC4-AFED-4C4C-BDA2-FE90F3F5212D.m4a</filename><size>28529</size><content-type>audio/x-m4a</content-type> > </request></iq> > > <iq xmlns="jabber:client" id="61528B53-923F-4687-B01B-EA4978E69920" > type="error" to="[email protected]/chatsecure49016" from=" > xmpp.example.com"><error type="modify"><bad-request > xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text > xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">MIME type does not match file > extension</text></error></iq> The thing is that mod_http_upload is not the one that decides what MIME type to use when the file is served / downloaded. This is done by mod_http_files, which also handles static file serving for sevral other modules. mod_http_upload tries to make sure that the file extension and the content type provided by the client will match what mod_http_files would pick. Also, if file type restrictions are enabled, making it trivial to bypass by simply lying in the mime-type field and having a different file extension doesnt't seem like the thing to do. It could be solved more cleanly if mod_http_upload also handled downloads, but that would probably involve a lot of duplication of code, of which I'm not really a fan. I would also like to point out that I consider mod_http_upload to be an experimental proof-of-concept that is unsuitable for production except for exchanging small images on small servers. mod_http_upload_external is a much more sane approach, look at that. One thing there is that it does not pass along the mime type. I it should do that, and include it in the signature. -- Zash -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
