In my experience octet-stream will always tell the browser to just download the file

Usually it's the other way around where you want the content type to be pdf or whatever for the browser to display it

it doesn't look like they are getting translated correctly on the S3 side.

Often times the issue is when saving the file, not retreiving it

The s3sdk has a setting to automatically guessing the mime type based on extension

Tho I forget if it's on or off by default

Ugh, yeah 97% chance Lucee screws it up

I doubt Lucee has any logic for that

That's why use the s3sdk for this stuff

It takes care of those things

You can set the headers, but prolly not with Lucee's abstracted file system functions, you'd need a proper s3 lib

I'm looking at the s3sdk's

getAuthenticatedURL()

to try and figure out how/where you'd pass the

response-content-type

bit

You wouldn't want to add it to the actual signing request-- maybe it would get tacked on to the

uri

? 🤔

I think the S3sdk will need updated to allow you to pass a

response-content-type

when signing a URL.

Just for completeness, here is the full list of headers that can be sent when signing a URL

response-content-type
response-content-language
response-expires
response-cache-control
response-content-disposition
response-content-encoding

I have added support for this in the

s3sdk

module and am publishing it now. You can set a custom content type response header like so

var presignedURL = s3.getAuthenticatedURL(
						bucketName      = testBucket,
						uri             = "example.txt",
						responseHeaders = { "content-type" : "text/plain" }
					);

or let the SDK choose the correct header based on the extension

var presignedURL = s3.getAuthenticatedURL(
						bucketName      = testBucket,
						uri             = "example.txt",
						responseHeaders = { "content-type" : "auto" }
					);

Now published in version

5.6.0