If the Content Type is passed when uploading an object, Minio should not attempt to double guess it / ignore it.
I'm setting a custom Content Type when putting an object but subsequent calls to HEAD/GET return a different Content Type.
I'm putting an object (using aws-sdk-js) with the following params:
{ ContentType: 'audio/mp4',
Bucket: 'filepunk-test',
Key: 'audio/whistling', }
Head returns:
{ AcceptRanges: 'bytes',
LastModified: 'Wed, 28 Sep 2016 00:46:07 GMT',
ContentLength: '299850',
ContentType: 'text/plain; charset=utf-8',
Metadata: {} }
Get returns:
{ AcceptRanges: 'bytes',
LastModified: 'Wed, 28 Sep 2016 00:46:07 GMT',
ContentLength: '299850',
ContentType: 'video/mp4',
Metadata: {},
It's now video/mp4 instead of audio/mp4.
Strangely, if I do the same put _without_ specifying a content type, head/get will now return a content type of application/octet-stream instead of video/mp4.
minio/minio docker image. I'm using docker-compose:
minio:
image: minio/minio
ports:
- "9000:9000"
volumes:
- ./test/.minio/data:/export
- ./test/.minio/config:/root/.minio
environment:
- "MINIO_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE"
- "MINIO_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
Docker for Mac
var AWS = require('aws-sdk');
var s3 = new AWS.S3({accessKeyId:'abcd1', secretAccessKey:'abcd1234', endpoint:'http://172.19.0.2:9000/', s3ForcePathStyle:true, signatureVersion:'v4'});
s3.createBucket({Bucket: 'filepunk-test'}, function() {
var params = {Bucket: 'filepunk-test', Key: 'audio/whistling', Body: 'data', ContentType:'audio/mp4'};
s3.putObject(params, function(err, data) {
if (err)
console.log(err)
else {
console.log("Successfully uploaded data");
s3.getObject({Bucket:'filepunk-test', Key:'audio/whistling'}, function(err, data) {
console.log("the content type of the download object is " + data.ContentType);
});
}
});
});
output:
Successfully uploaded data │
the content type of the download object is audio/mp4
@olalonde, I tested the above javascript code against minio:edge docker image (with docker-compose) and it works as expected. Could you paste your code ?
@vadmeste I don't know what I was smoking yesterday but I just re-ran the same code and it is now working as expected (still ~same code and on the same minio/minio container). Perhaps it's a difficult to reproduce bug (involving lots of overwrites to the same key, because my tests were doing that by auto running every time I save a file in vim) or maybe I was just too tired yesterday and missed something obvious... Will close for now and will re-open if I see the same issue again.
@vadmeste I don't know what I was smoking yesterday but I just re-ran the same code and it is now working as expected (still ~same code and on the same minio/minio container). Perhaps it's a difficult to reproduce bug (involving lots of overwrites to the same key, because my tests were doing that by auto running every time I save a file in vim) or maybe I was just too tired yesterday and missed something obvious... Will close for now and will re-open if I see the same issue again.
Thanks @olalonde
Most helpful comment
@vadmeste I don't know what I was smoking yesterday but I just re-ran the same code and it is now working as expected (still ~same code and on the same minio/minio container). Perhaps it's a difficult to reproduce bug (involving lots of overwrites to the same key, because my tests were doing that by auto running every time I save a file in vim) or maybe I was just too tired yesterday and missed something obvious... Will close for now and will re-open if I see the same issue again.