[MGNLUI-6670] mime types of files uploaded via FileUpload field are not resolved correctly Created: 22/Apr/21  Updated: 24/May/21  Resolved: 21/May/21

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 6.2
Fix Version/s: 6.2.9

Type: Bug Priority: Major
Reporter: Tomáš Gregovský Assignee: Adam Siska
Resolution: Fixed Votes: 2
Labels: maintenance
Remaining Estimate: 0d
Time Spent: 1.5h
Original Estimate: Not Specified

Attachments: PNG File Screenshot_2021-04-26_at_10_48_03.png    
Issue Links:
Cloners
is cloned by MGNLDAM-965 Mime types of files uploaded via Zip-... Closed
Relates
relates to MGNLUI-6390 allowedMimeTypePattern property doesn... Closed
relation
Template:
Acceptance criteria:
[ ]* resolve mime types of JS and CSV correctly
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[X]* Steps to reproduce, expected, and actual results filled
[X]* Affected version filled
Date of First Response:
Sprint: Maintenance 58

 Description   

 

When uploading non-binary asset, the mime type is always shown as text/plain making it difficult to know when it is actually stored incorrectly.

The incorrect stored mime type case happens when uploading via zip-upload.

To reproduce (visual issue):

  1. upload non image file such as js or csv via upload field
  2. Observe resolved mime type (should be correct)
  3. save the asset
  4. open again for editing
  5. Observe resolved mime type (note that this is just a visual error, actual type stored in jcr is correct!)

 

To reproduce (in repo):

  1. pack an image in a zip file
  2. zip-upload file with image into dam via Assets app action
  3. observe stored mimetype (eg vie JCR Tools/Dumper or via export of the asset)


 Comments   
Comment by Jan Haderka [ 23/Apr/21 ]

Magnolia uses Tika for detecting mime types.

Tika seems to have issues w/ detection, here eg for math files, but in general to fix the issue, either Tika needs to be fixed, or replaces its usage by something more up to date.

Semi-random examples of wrong types detection by Tika:

js -> text/plain instead of text/javascript

csv -> text/plain instead of text/csv 

Comment by Jan Haderka [ 23/Apr/21 ]

Solved by passing whole file to Tika instead of just input stream so that filename/extension can be used to help resolving correct type.

Comment by Jan Haderka [ 26/Apr/21 ]

Seems to be visual issue only. Stored value in JCR comes from different part of the code and is correct.

 

avongunten perhaps something for your list? Should be quick to fix it so that the displayed value matches the stored one.

Generated at Mon Feb 12 09:38:50 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.