Lifecycle policy specification includes:
Cluster setting
Policy headers header on domain Bucket policies stored in Swarm storage (as headers)objects (optional)
Policy headers on bucket objects
Cluster Setting Values
The Swarm cluster setting policy.lifecycle
supports two values:
...
<unspecified> – The lack of a defined policy header means that lifecycle policies are only enabled for buckets in the domain when the
policy.lifecycle
setting is enabled. This means that setting the policy at the domain level is optional.enabled – The lifecycle policies are enabled for buckets in a domain when the
policy.lifecycle
cluster setting is enabled.disabled – The lifecycle policies are disabled for buckets in a domain regardless of
policy.lifecycle
setting. ThePolicy-Lifecycle
value may be prefixed with<cluster name>=...
, meaning that the policy only applies within the specified cluster. Multiple values are allowed if this feature is used.
Info |
---|
Lifecycle policy does not apply to unnamed content within a domain. Only named objects within buckets will have lifecycle policy applied to them. |
...
Each header value encodes one lifecycle policy . Each Policy-Lifecycle complete rule value is suffixed with “:<cluster name>”, meaning that the policy applies within the specified cluster.
Each lifecycle rule is comprised of a number of optional attributes, expressed as <name>:<value> pairs separated by space. Extra spaces are allowed at the beginning, end, and before & after the colon.
Important
Duplicate names are not allowed in a lifecycle ruleacross lifecycle rules for a bucket.
Unsupported names or values result in an 400 error on the bucket (or domain) write. The 400 response will indicate the source of the problem.
Supported Rule Attributes
Attribute | Value | Definition | ||
---|---|---|---|---|
RuleId | <unique rule id> | A required, user-defined id of the rule. The value must be contained within quotes. Values within the quotes must be URL-encoded. | ||
Enabled | <true|false> | An optional indication to confirm whether the rule is enabled or not. The absence of this attribute indicates the rule enabled. | ||
NamePrefix | <prefix> | An optional prefix to be matched against the relative name of the object in question.
| ||
ExpirationDays | <nonnegative integer> | The current version of an object is expired after the defined number of days. | ||
ExpirationDate | <ISO 8601 date> | The current version of an object is expired after the defined date (midnight UTC time). | ||
ObsoleteExpirationDays | <nonnegative integer> | A non-current version of an object is expired after the defined number of days when the object becomes non-current.
| ||
ObsoleteExpirationDate | <ISO 8601 date> | A non-current version of the object is expired after the defined date (midnight UTC time).
|
...
For expiration days,
Expiration time = Creation time of the current version + Number of days indicated + Rounded up to the next midnight UTCFor obsolete expiration days,
Expiration time = Create time of the next newest object version + Number of days indicated + Rounded up to the next midnight UTCISO 8601 dates must unambiguously specify a calendar date. The (unspecified) expiration time is always midnight UTC of that date, so any timezone specification is not allowed.
Expiration of a current version of an object (i.e. non-delete marker in the versioning enabled bucket) means creating a delete marker, pushing the current version down the versioning stack.
In all other cases, the object or object version is permanently deleted.
...
Swarm Content Portal provides a convenient method of managing policies. This information is provided for completeness.
Info |
---|
Since lifecycle policies are part of the overall context-level policy framework, GET and HEAD requests on contexts and name objects (with the verbose query argument) return |
...