I need to be able to change the MIME content type of a key after creating it in Tigris.
The AWS API is extremely poorly designed, and doesn’t provide a means of editing metadata of a key after creation; however, one of the workarounds I’ve used with S3 was calling CopyObject and setting the source and destination to the same key, with a new ContentType specified. This workaround incurs a cost, but at least allows me to update the content type! Sadly, this workaround does not appear to work with the Tigris API.
Can anybody advise on a means of resolving this, or another possible workaround…? I’ve been impressed with Tigris thus far, but I think the AWS API (and their periodic divergences from compatibility with it) are hurting them.
That workaround should work for Tigris as well. Could you try by passing the header x-amz-metadata-directive with value as REPLACE i.e. x-amz-metadata-directive:REPLACE and pass all the headers that you need? Then it will perform the copy operation by honoring the metadata in the copy request. Basically, If this header isn’t specified, default directive is “COPY” which means copying all the metadata from the source key and as source and destination are same that’s why you were seeing the error.
That does, in fact, work! Thank you. Every time I discover some new, terrible facet of the AWS API like this I am amazed that folks like you guys have dedicated time to replicating it.
I really appreciate your help, and the blazing-fast response
Yeah the S3 api is not very use friendly in many aspects. We do plan on enhancing the API, i.e. supporting the S3 API like we do today but extending it to make it more user friendly.
Not that my opinion here matters, but: I think you guys would probably be much better off designing your own API from scratch and offering the AWS API in parallel. The functionality provided by S3 is reasonably straightforward to model using REST semantics, and it would be so nice to see lightweight, sane client libraries – especially for Python (lol). I’m assuming that’s a pretty massive engineering effort on your end, but I suspect Tigris’s use of FDB means there’s a ton of interesting functionality you could provide if your hands weren’t tied by Amazon’s poor API design and client library implementations.
As an aside: I’m really looking forward to being able to designate an index.html for public buckets. Would be nice to serve my static site directly from Tigris.
I’m enjoying Tigris, thus far! Keep up the good work
S3’s API design does tie our hands. But we have to have the API compatibility. It makes it easier for folks to adopt us. There are so many products/tools/libraries that work with S3 API, and folks are used to it. So it is better to start off with S3 API as the base and then build extensions. The extensions to the API do not necessarily have to follow S3’s API design.
And yes, you are right, FDB allows us the ability to offer a lot of interesting functionality, such as secondary indexes on objects, etc. We will be building this functionality and make it available through API extensions. But who knows, maybe we will offer an alternate API as well.
“Ability to designate an index.html for public buckets” - this is planned. It’s just that there is other high priority work we are focusing on at the moment (storage tiers, object notification, etc).
I am glad you are enjoying Tigris. Keep the feedback coming
