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
Comments
Since Mines has neither test nor document, should it be better to deprecated and recommend using Files.probeContentType? |
I'm fine with deprecating and eventually removing it, but it's currently being used in scalatra/core/src/main/scala/org/scalatra/ScalatraBase.scala Lines 288 to 290 in c7f214d
In that case, the Content-Type auto-inference feature would have to be removed (which I believe never worked properly anyway). |
It may be possible to use 'java.net.URLConnection.guessContentTypeFromStream' |
I will organize it a little more and write a PR |
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/ |
Added MIME type customization example to the test |
Oh, I will fix it because the test passed by me does not go through Travis. PR will close. |
Can I close this issue? |
Mimes
trait seems to always returnapplication/octet-stream
as MIME type.Currently:
Expected:
Problem:
mimeUtil
is a definition instead of a variable. Every timemimeUtil
is used it creates a brand new instance ofMimeUtil2
and looses theMimeDetector
registrations.scalatra/core/src/main/scala/org/scalatra/util/Mimes.scala
Lines 38 to 40 in 0474fb3
Solution:
Make
mimeUtil
aval
instead ofdef
in the traitorg.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.Now the problem is coming from
eu.medsea.mimeutil
library, which has bothapplication/x-pointplus
andtext/css
MIME types associated with the extension.css
, and will pick one of them mostly randomly (both MIME types end up inside aHashSet
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.
The text was updated successfully, but these errors were encountered: