Thanks for following up! Your reasoning makes sense but I still feel that
being overly strict about mime type / file extension mappings isn't
necessary, and should perhaps be relaxed by mod_http_files. I'll take a
look at _external.

On Thu, Jul 6, 2017 at 6:01 AM, Kim Alvefur <z...@zash.se> wrote:

> 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.
>

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