Being able to set 'content-type' to a resource before uploading to an S3 bucket

[yngwuoso]

I see that org.springframework.cloud.aws.core.io.s3.SimpleStorageResource.SimpleStorageOutputStream.finishSimpleUpload() doesn't take into account the content-type of the content.

Can you take it into account and find a solution?

Regards.

[pacey]

This would be super handy. All of the objects I've been uploading have the content-type application/octet-stream which isn't great

[pacey]

From digging into the aws java sdk it would appear that for a simple put object request it will actually set the correct content-type metadata on the object for you. I've seen this behaviour using it from spring-cloud-aws too. However, the multipart upload api doesn't do this behaviour and I've raised an issue to discuss adding this aws/aws-sdk-java#1648.

I think it would still be nice to set the content-type on the SimpleStorageResource and not rely on the aws s3 sdk to do this. I would be happy to contribute for this change, if one of the main contributors could point me in the right direction.

One possible, albeit a bit ugly, solution to this would be to have a setContentType method on the SimpleStorageOutputStream class. But granted, that isn't encapsulated very well. The content type could be set on the SimpleStorageResource, however this might be confusing if you "get" a resource and then change it's content type it wouldn't actually be updated in S3.

[paulcwarren]

This would be useful for me too and, in fact, I would be happy to have a shot at implementing it but I dont think the setContentType on SimpleStorageOutputStream would be accepted by the Spring team honestly. The problem I forsee with this approach is that WritableResource.getOutputStream returns OutputStream, not SimpleStorageOutputStream and therefore a consumer would have to know the resource they have in hand and cast it in order to set the content type.

So, what about modifying SimpleStorageProtocolResolver as follows:

    @Override
    public Resource resolve(String location, ResourceLoader resourceLoader) {
        if (SimpleStorageNameUtils.isSimpleStorageResource(location)) {
            return new SimpleStorageResource(this.amazonS3, SimpleStorageNameUtils.getBucketNameFromLocation(location),
                    SimpleStorageNameUtils.getObjectNameFromLocation(location), this.taskExecutor,
                    SimpleStorageNameUtils.getVersionIdFromLocation(location), SimpleStorageNameUtils.getContentTypeFromLocation(location));
        } else {
            return null;
        }
    }

and SimpleStorageResource as follows:

SimpleStorageResource(AmazonS3 amazonS3, String bucketName, String objectName, TaskExecutor taskExecutor, String versionId, String contentType)

i.e. infer the content-type from the file extension of the resource.

This has the advantages that it requires no changes to the "API". Works in a way often used by other web and file-based resources and, in fact, how AWS SDK's putObject works when you give it a java.io.File instead of an InputStream.

The downside here is that the object name (and therefore s3 key) would also include a file extension. We could also modify getObjectNameFromLocation to remove the extension in much the same way it removes the version id. But again, I wonder what the Spring team would think about this. To me, it seems like it might be viewed as undesirable complexity/a backwards compatibility issue.