aws-s3 icon indicating copy to clipboard operation
aws-s3 copied to clipboard

Expose content-type/content-encoding etc in the content type

Open hypirion opened this issue 1 year ago • 5 comments

Hi, thanks for a nice library!

I am using S3.put with the content_type parameter to specify the type of the S3 object I uploaded, and I'd like to retrieve that information somehow. However, head/ls returns content types, and that one doesn't expose the Content-Type stored on the object (it's not in the meta_headers either, I checked).

Would it make sense to add this and other common S3 fields to the content type?

hypirion avatar Sep 07 '24 22:09 hypirion

I think it makes perfect sense to extend the content type to include the content type and other useful headers. What other common fields are you thinking of?

andersfugmann avatar Sep 09 '24 07:09 andersfugmann

Looking further into this, the ListObjects call does not return the content type for each entry (doc). So content type would be empty on each ls. I think the only way to get the content type is though get/head operations (which is actually strange).

I'm cautious not to extend the content type to include too many fields with an option type, but I'll gladly review a PR.

andersfugmann avatar Sep 09 '24 08:09 andersfugmann

I'd think people would at least like the API to be symmetric -- currently it's possible to send in content_type, content_encoding and cache_control via put, so I'd assume people would like to be able to retrieve those values as well.

If it makes more sense to you, I can make a head_v2 or something that returns a new type, to avoid polluting the current content type with too many unset values for ls.

hypirion avatar Sep 09 '24 08:09 hypirion

Hmm... Having a second version for head would also pollute the namespace - and we would need a solution for get also which I assume will return the same header as for head.

I'm considering two solutions. Extend content type with a optional field pointing to record containing the additional three elements, but that only makes sense if the three are always present (don't really want a record with three optional fields). An alternative could be to just return all headers as an assoc list and provide useful constants to access the fields in this list.

Thoughts.

andersfugmann avatar Sep 09 '24 14:09 andersfugmann

I think it'd be just fine to have them all in a headers field. The end result would be the same for me at least.

hypirion avatar Sep 11 '24 11:09 hypirion