Repository navigation
Expose content-type/content-encoding etc in the content type #37
Description
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?
Activity
andersfugmann commentedon Sep 9, 2024
I think it makes perfect sense to extend the
contenttype to include the content type and other useful headers. What other common fields are you thinking of?andersfugmann commentedon Sep 9, 2024
Looking further into this, the
ListObjectscall 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
contenttype to include too many fields with an option type, but I'll gladly review a PR.hypirion commentedon Sep 9, 2024
I'd think people would at least like the API to be symmetric -- currently it's possible to send in
content_type,content_encodingandcache_controlviaput, 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_v2or something that returns a new type, to avoid polluting the current content type with too many unset values forls.andersfugmann commentedon Sep 9, 2024
Hmm... Having a second version for
headwould also pollute the namespace - and we would need a solution forgetalso which I assume will return the same header as for head.I'm considering two solutions. Extend
contenttype 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 commentedon Sep 11, 2024
I think it'd be just fine to have them all in a
headersfield. The end result would be the same for me at least.