2

When publishing a binary with Tridion, does the Tridion Deployer set the MimeType that is used on the final destination? What about for MP4 files? Tridion OOTB does not have an MP4 MimeType, so we added it on the backend CMS. But, does this mean the Deployer also doesn't know about it?

We're using a Custom Storage Extension in the Deployer to write the files to Amazon S3. For MP4 files we're getting a MimeType of 'application/octet-stream' and not 'video/mp4'. I saw a solution to fix this within S3 here, but not sure if this could be a problem within our Storage Extension itself.

  • 1
    Sounds to me like a problem with the storage extension itself indeed, first thing you could check is if you deploy other binaries (like an image or a zip file), do they also get an unexpected mimetype? Next I would check out if the type is set correcty in the Transport Package, check out the binaries.xml file. – Bart Koopman Apr 2 '15 at 11:42
2

Since you are using a custom storage extension, as mentioned in my comment, I think the error is in there.

As Peter mentions, the mime type is not part of the file, but should be set by the web application serving the file.

If you have added an additional mime type in Tridion, and that is also used when calling AddBinary in your TBB, then you should have it available in the Storage Extension.

Either use one of the overloads of AddBinary, like engine.PublishingContext.RenderedItem.AddBinary(stream, filename, sg, variant, relatedComponent, mimeType);, or the default which I expect sets the mime type from the multimedia Component.

A rough guess would be to adjust the following code in the Storage Extension:

public void configure() throws Exception {
    from("direct:awss3")
        .setHeader(S3Constants.KEY, method(this, "stripFirstChar(${in.header.CamelFileName})"))
        .setHeader(S3Constants.CONTENT_LENGTH, simple("${in.header.CamelFileLength}"))
        .to("aws-s3://" + s3Url)
        .log("ETAG for saved resource is ${in.header.CamelAwsS3ETag}");
}

That will need the mime type (or content type as it is also called) set in the header. There might be something like S3Constants.CONTENT_TYPE available.

2

MIME types (or "Internet media types" as they are known these days) are not stored in the file itself, so the Content Deployer isn't involved.

The type should be set in the response headers by the web server, when it serves the file.

For example, I might store a file as a simple text file -- and then have my web server return it as "text/html" if I want the browser to treat it as an HTML page -- or "text/plain" if I want it to treat it as a raw plain-text file. That wouldn't be possible if the type was part of the file.

  • A bit of additional info, the Deployer should know the mime type of each of the binaries it needs to deploy btw. If you look at the binaries.xml file in a Transport package, you see a Type listed there for each binary. – Bart Koopman Apr 2 '15 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.