S3 and Swift both support expiring objects in some form, but the
semantics are entirely different.
In S3, expiration policy is at the bucket level. A client calls
PutBucketLifecycleConfiguration to specify bucket lifecycle rules;
some of these rules enable object expiration. After that API call,
the rules take effect within a few hours for all objects in the bucket.
In Swift, expiration policy is at the object level. When uploading an
object, a client can add the header “X-Delete-At: T” or
“X-Delete-After: D”, where T is a Unix timestamp and D is a duration
in seconds. That object will then expire at either time T or at
D seconds after the PUT request was made.
S3 object GET and HEAD responses for expiring objects contain the time
at which the object will expire based on the current bucket configuration
as well as the rule responsible. This is in the “X-Amz-Expiration” header.
Example:
x-amz-expiration: expiry-date="Fri, 16 Jan 2026 00:00:00 GMT",
rule-id="logs-expiration"
This patch adds this support into Swift’s S3API for expiring objects.
Swift's S3API does not currently support expiration via bucket lifecycle
policies, so the x-delete-at header is the only possible source of
expiration time to be returned in the x-amz-expiration header. However,
if bucket lifecycle expiration were to be implemented then the
x-amz-expiration header could return the lowest of the bucket expiration
time or the x-delete-at time.
Adds Sam, who came up with this approach, as co-author.
Change-Id: I9e319b75c557d5ab971182adb4aa10ad27a14d0b
Co-authored-by: Samuel Merritt <smerritt@nvidia.com>
Signed-off-by: Jianjian Huo <jhuo@nvidia.com>
7ddc6ef4d9