search

andersfugmann / aws-s3

Ocaml library to access Amazon S3
https://andersfugmann.github.io/aws-s3/
BSD 3-Clause "New" or "Revised" License
49 stars 13 forks source link

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

Open hypirion opened 1 month ago

hypirion commented 1 month ago

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?

andersfugmann commented 1 month ago

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 commented 1 month ago

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.

hypirion commented 1 month ago

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.

andersfugmann commented 1 month ago

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.

hypirion commented 1 month ago

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.