S3Object.head return content-encoding with response about aws-sdk-ruby HOT 9 CLOSED

In general, it would be nice to have access to any object metadata that does not begin with x-amz-meta-

This is where the filtering takes place:
https://github.com/aws/aws-sdk-ruby/blob/master/lib/aws/s3/client.rb#L914

The fix is trivial, but requires Amazon to make a design decision. @trevorrowe ?

from aws-sdk-ruby.

The :metadata of an object stored in S3 is defined as the user-supplied hash of metadata. I don't think mixing additional HTTP response headers into the user metadata hash would be the correct solution here.

Using rspec syntax this is what I mean:

s3.buckets['aws-sdk'].objects['key'].write(data, :metadata => meta)
s3.buckets['aws-sdk'].objects['key'].metadata.to_h.should eq(meta)

I agree that the additional http response headers should be accessible. Would it be sufficient if all of the other header values were merged into the response data from #head_object?

resp = s3.client.head_object(...)
resp[:content_encoding] #=> '...'

from aws-sdk-ruby.

@trevorrowe Admittedly, there is an issue with mixed concerns here. Unfortunately the fact still stands that fields like Content-Disposition are valid user-supplied metadata that can be set on the S3 object and retrieved when you GET/HEAD that object in all other circumstances. In fact the console allows you to set more or less any header on the object for retrieval.

I think what you say makes sense - it does seem logical to have a mechanism for retrieving x-amz-meta- only, keeping the standard (or other non-standard) HTTP headers as a separate concern.

from aws-sdk-ruby.

Sorry, close/reopen on accident.

I believe returning the other HTTP headers in the head_object response is the right approach and as you've both pointed out, keeps the non-HTTP S3 meta as a separate concern.

from aws-sdk-ruby.

+1

I was surprised that there was no easy way to access the Cache-Control header set on my objects. It would be great if head_object returned all the header values that can be set via write or copy_to, otherwise you have some headers that are write-only!

from aws-sdk-ruby.

👍

I'm trying to compare local files that may or may not have been gzipped to their S3 counterparts and not finding a way to do so. Is there currently any way to fetch content encoding using the Ruby SDK?

from aws-sdk-ruby.

@mbleigh I'm also here for this reason. Would be very helpful to be able to read content_encoding.

from aws-sdk-ruby.

I went ahead and added the headers identified in this issue to the #get_object and #head_object client responses. I'm avoiding making other sweeping changes at this time because we are currently looking into more major changes related to the AWS::S3::Client that would accompany a major version bump (e.g. v2.0). These changes would include a few backwards incompatible changes.

Primarily I want to get rid of the hand-coded s3 client and replace it with a modeled client using a service model. Similar service models are being used by the new Node.js SDK, the unified aws-cli, the new PHP SDK and boto core.

from aws-sdk-ruby.

Content-Disposition was mentioned in this thread, but I don't see it in the Feb. 26, 2013 update. Was there a reason this was left out? Like others, I can't figure out any way to read a content-disposition header using the Ruby SDK.

from aws-sdk-ruby.