Closed jo-pol closed 3 weeks ago
We tested the zip file included in this issue and are able to duplicate the bug. The system recognizes the file type once we upload the m4a file by itself.
One thing that's strange is when you call the redetect API on both the one from the zipped and the one that was direct:
from zip file:
{"status":"OK","data":{"dryRun":true,"oldContentType":"application/octet-stream","newContentType":"application/octet-stream"}}
from direct: {"status":"OK","data":{"dryRun":true,"oldContentType":"audio/x-m4a","newContentType":"application/octet-stream"}
which means it would change it to be the same as the one where it didn't detect it... why would that be? and how did it correctly detect it on upload?
If the browser supplies a mimetype, we use it if our internal detection only gives application/octet-stream.
Right, here's how we document this behavior:
"Please note that it’s possible to “trick” a Dataverse installation into giving a file a content type (MIME type) of your choosing. For example, you can make a text file be treated like a video file with -F 'file=@README.txt;type=video/mpeg4', for example. If the Dataverse installation does not properly detect a file type, specifying the content type via API like this a potential workaround."
-- https://guides.dataverse.org/en/6.4/api/native-api.html#add-a-file-to-a-dataset
What steps does it take to reproduce the issue?
Upload toolsfairy-audio.zip on a dataset page
dataset page
The filet gets contentType
application/octet-stream
all
The file should get contentType
audio/x-m4a
like when uploading the individual files with chromeWhich version of Dataverse are you using?
v. 6.4 build 1609-906f874
Any related open or closed issues to this bug report?
https://github.com/gdcc/dataverse-ansible/pull/375 to show the previewer for the proper content type
Are you thinking about creating a pull request for this issue? yes