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:
> 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
> > default
> > https://www.apt-browse.org/browse/debian/jessie/main/all/
> > 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
> > and audio/x-m4a should be similarly valid.
> > I'm not really sure what to do here as a client developer because it
> > that many servers will be running this extension and rejecting all sorts
> > 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
> > unexpected mime type and just trust the clients to do the right thing,
> > 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-
> > </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
> > 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.
> 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 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.
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 email@example.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.