Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mimes trait detects the wrong MIME type #830

Closed
helfper opened this issue May 25, 2018 · 9 comments
Closed

Mimes trait detects the wrong MIME type #830

helfper opened this issue May 25, 2018 · 9 comments
Labels
Milestone

Comments

@helfper
Copy link

helfper commented May 25, 2018

Mimes trait seems to always return application/octet-stream as MIME type.

Currently:

scala> MimeTypes.mimeType("test.html")
res0: String = application/octet-stream

Expected:

scala> MimeTypes.mimeType("test.html")
res0: String = text/html

Problem:

mimeUtil is a definition instead of a variable. Every time mimeUtil is used it creates a brand new instance of MimeUtil2 and looses the MimeDetector registrations.

protected[this] def mimeUtil: MimeUtil2 = new MimeUtil2()
quiet { mimeUtil.registerMimeDetector("eu.medsea.mimeutil.detector.MagicMimeMimeDetector") }
quiet { mimeUtil.registerMimeDetector("eu.medsea.mimeutil.detector.ExtensionMimeDetector") }

Solution:

Make mimeUtil a val instead of def in the trait org.scalatra.util.Mimes


Unfortunately, that's not the end of the story. Even with that fix, Mimes returns the wrong MIME type for CSS files.

scala> MimeTypes.mimeType("test.css")
res1: String = application/x-pointplus

Now the problem is coming from eu.medsea.mimeutil library, which has both application/x-pointplus and text/css MIME types associated with the extension .css, and will pick one of them mostly randomly (both MIME types end up inside a HashSet at some point, so it's not guaranteed which one will come out first). This, from my point of view, makes this library unfit for purpose.

Other projects have already moved away from that library, being Apache Marmotta one of them that chose Apache Tika as an alternative (https://git-wip-us.apache.org/repos/asf?p=marmotta.git;a=commitdiff;h=f89f61f2128fcb70db885b31b42077782ad411a6), and it seems it's a quite reliable library.

scala> tika = new org.apache.tika.Tika
tika: org.apache.tika.Tika = Apache Tika 1.18

scala> tika.detect("test.html")
res2: String = text/html

scala> tika.detect("test.css")
res3: String = text/css
@takezoe takezoe added the bug label May 27, 2018
@magnolia-k
Copy link
Contributor

Since Mines has neither test nor document, should it be better to deprecated and recommend using Files.probeContentType?

@helfper
Copy link
Author

helfper commented May 29, 2018

I'm fine with deprecating and eventually removing it, but it's currently being used in ScalatraBase in a way that is not covered by Files.probeContentType AFAIK:

case bytes: Array[Byte] => MimeTypes(bytes)
case is: java.io.InputStream => MimeTypes(is)
case file: File => MimeTypes(file)

In that case, the Content-Type auto-inference feature would have to be removed (which I believe never worked properly anyway).

@magnolia-k
Copy link
Contributor

It may be possible to use 'java.net.URLConnection.guessContentTypeFromStream'

@magnolia-k
Copy link
Contributor

I will organize it a little more and write a PR

@magnolia-k
Copy link
Contributor

I created PR to modify MIME Type guess against file path to use URLConnection.guessContentTypeFromName

This makes it possible to add an arbitrary MIME Type on the user code side.

It is good to refer to the following blog

https://thilosdevblog.wordpress.com/2011/06/27/mime-types-in-java/

#836

@magnolia-k
Copy link
Contributor

Added MIME type customization example to the test

03b0fbd

@magnolia-k
Copy link
Contributor

Oh, I will fix it because the test passed by me does not go through Travis. PR will close.

@magnolia-k
Copy link
Contributor

#839

@takezoe takezoe added this to the 2.7.0 milestone Jun 24, 2018
@takezoe
Copy link
Member

takezoe commented Jun 24, 2018

Can I close this issue?

@takezoe takezoe closed this as completed Jun 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants