Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hypirion opened this issue Sep 7, 2024 · 5 comments
Open

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

hypirion opened this issue Sep 7, 2024 · 5 comments

Comments

@hypirion
Copy link

hypirion commented Sep 7, 2024

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

hypirion commented 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_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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants