Do not return invalid content type on text files

[inkstak]

Fixes #2424

It also supports this edge case:
I have to deal with text files provided by public administrations with inconsistent extensions ( .N000777, .BATI, .txt, missing extensions) alongside known extensions (.csv, .pdf, images, etc.)

Returning a missing content type is quite different from returning an invalid content type.

[n-rodriguez]

Hi there! Any news?

[n-rodriguez]

Hi there! Any news?

[krasnoukhov]

I'm curious why you didn't go with your original approach for image/* check only? There are a lot of other options like application/* or audio/* for which the issue will still be relevant

[inkstak]

The actual strategy on carrierwave is giving high confidence in the result of MimeMagic.by_magic:

• If it returns something : it's valid
• If it returns nothing : it's invalid

The approach I suggested in #2424 doesn't trust the result and still considers missing types as invalid:

• If it returns an image : we double-check the type from the filename
• If it's present but anything other than an image : it's valid
• If it returns nothing : it's still invalid

The final solution tries to keep confidence in MimeMagic.by_magic but considers the nothing case:

• If it returns something : it's still valid.
• If it returns nothing : we double-check the type from the file name:
  • if it's still missing : it's just something unknown so let's return nil
  • if it looks like text : the types don't match but there is no risk in considering it valid
  • if it's anything else : it looks like type spoofing so let's return invalid type

I guess images, audio or video files not detected as such by MimeMagic.by_magic should be considered at risk as they can then be processed by sub-programs, added and played from HTML pages.

I've mixed feelings about application/* because it covers a lot of cases.

[zjeraar]

Any chance of merging this?

[mshibuya]

Thank you and sorry for delay.