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="simula...@example.com/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 prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.

Reply via email to