• Object Storage Service

obs
  1. Help Center
  2. Object Storage Service
  3. API Reference (OBS)
  4. Operations on Buckets
  5. PUT Bucket lifecycle
  6. Requests

Requests

Syntax

PUT /?lifecycle HTTP/1.1
User-Agent: user-agent
Host: bucketname.obs.example.com
Content-Length: length
Date: date
Authorization: authorization
Content-MD5: MD5
Expect: expect

<?xml version="1.0" encoding="UTF-8"?>
<LifecycleConfiguration>
 <Rule>
  <ID>id</ID>
  <Prefix>prefix</Prefix>
  <Status>status</Status>
  <Expiration>
   <Days>365</Days>
  </Expiration>
  <NoncurrentVersionExpiration>
   <NoncurrentDays>365</NoncurrentDays>
  </NoncurrentVersionExpiration>
  <Transition> 
   <Days>30</Days> 
   <StorageClass>STANDARD_IA</StorageClass> 
  </Transition> 
  <Transition> 
   <Days>60</Days> 
   <StorageClass>GLACIER</StorageClass> 
  </Transition> 
  <NoncurrentVersionTransition> 
   <NoncurrentDays>30</NoncurrentDays> 
   <StorageClass>STANDARD_IA</StorageClass> 
  </NoncurrentVersionTransition> 
  <NoncurrentVersionTransition> 
   <NoncurrentDays>60</NoncurrentDays> 
   <StorageClass>GLACIER</StorageClass> 
  </NoncurrentVersionTransition> 
 </Rule>
</LifecycleConfiguration>

Request Parameters

This request involves no parameters.

Request Headers

The request uses one header, as described in Table 1.

Table 1 Request header

Header

Description

Remarks

Content-MD5

The MD5 digest string of the message body is calculated according to the RFC 1864 standard. That is, calculate the 128-bit binary array (the message header data encrypted with MD5) first, and then use Base 64 encoding to convert the binary data to a character string.

Type: String

Example: n58IG6hfM7vqI4K0vnWpog==

Mandatory

x-amz-security-token

Header field used to identify the request of a federated user. When the federal authentication function is enabled, users sending such requests are identified as federated users.

Type: string

Optional. This parameter must be carried in the request sent by federated users.

Request Elements

In this request, you need to specify the lifecycle configuration in the request body using the elements described in Table 2.

Table 2 Request elements for lifecycle configuration

Element

Description

Remarks

Date

Indicates when the specified rule takes effect (applicable to the latest object version).

The date value must conform to ISO 8601 format. The time is always midnight UTC.

Type: String

Ancestor: Expiration, Transition

Mandatory if the Days parameter is absent.

Days

Indicates the number of days after object creation when the specified rule takes effect.

Type: Positive integer

Ancestor: Expiration, Transition

Mandatory if the Date parameter is absent.

StorageClass

Indicates the new storage class of the object.

Type: STANDARD_IA or GLACIER

Ancestor: Transition, NoncurrentVersionTransition

Mandatory if Transition or NoncurrentVersionTransition is present.

Transition

Indicates the element of the transition time and new storage class (applicable to the latest version of the object) in the lifecycle configuration.

Type: XML

Children: Date or Days, StorageClass

Ancestor: Rule

Mandatory if NoncurrentVersionTransition, Expiration, and NoncurrentVersionExpiration are absent.

Expiration

Indicates the container for the object expiration rule.

Type: XML

Children: Date or Days

Ancestor: Rule

Mandatory if Transition, NoncurrentVersionTransition, and NoncurrentVersionExpiration are absent.

ID

Indicates the unique identifier of a rule. The value can contain a maximum of 255 characters.

Type: String

Ancestor: Rule

Optional

LifecycleConfiguration

Indicates the container for lifecycle rules. You can add multiple rules. The total size of the rules cannot exceed 20 KB.

Type: XML

Children: Rule

Ancestor: None

Mandatory

NoncurrentDays

Indicates the number of days after object is noncurrent when the specified rule takes effect.

Type: Positive integer

Ancestor: NoncurrentVersionExpiration, NoncurrentVersionTransition

Mandatory if the NoncurrentVersionExpiration or NoncurrentVersionTransition parameter is present.

NoncurrentVersionTransition

Indicates the element of the transition time and new storage class (applicable to historical versions) in the lifecycle configuration.

Type: XML

Children: NoncurrentDays, StorageClass

Ancestor: Rule

Mandatory if Transition, Expiration, and NoncurrentVersionExpiration are absent.

NoncurrentVersionExpiration

Indicates the container for the noncurrent object expiration rule. You set this lifecycle configuration action on a bucket that has versioning enabled (or suspended) to request that OBS delete noncurrent object versions which meet the expiration rule.

Type: XML

Children: NoncurrentDays

Ancestor: Rule

Mandatory if Transition, Expiration, and NoncurrentVersionTransition are absent.

Prefix

Indicates the object key prefix identifying one or more objects to which the rule applies.

Type: String

Ancestor: Rule

Mandatory

Rule

Indicates the container for lifecycle rules.

Type: Container

Ancestor: LifecycleConfiguration

Mandatory

Status

Indicates whether the rule is enabled.

Type: String

Ancestor: Rule

Valid Values: Enabled, Disabled

Mandatory

If the multi-version of a bucket is enabled or suspended, you can set NoncurrentVersionExpiration or NoncurrentVersionTransition to control the lifecycle of historical object versions. The lifecycle of a historical version depends on the time when the version becomes a historical one, that is, the version is overwritten by a new version (NoncurrentDays).

In deletion circumstances, if NoncurrentDays is 1, a version can only be deleted one day after it has become a historical version. For example, the V1 version of object A is created on the first day of a month, and its new version V2 is uploaded on the fifth day of the month. Then V1 becomes a historical version. One day later, that is, when the 0 o'clock of the seventh day comes, V1 expires. If an object version does not meet the deletion conditions, NoncurrentDays is 1, and StorageClass is STANDARD_IA, a version transitions to the Warm storage class one day after it has become a historical version. For example, the V1 version of object A is created on the first day of a month, and its new version V2 is uploaded on the fifth day of the month. Then V1 becomes a historical version. One day later, that is, when the 0 o'clock of the seventh day comes, V1 transitions to the Warm storage class. (Remarks: There is a delay of less than 48 hours for such a deletion or transition upon object expiration.)

The following lists the background processing for when the multi-version of a bucket is enabled or suspended and the object of the latest version meets expiration rules:

  • The multi-version of the bucket is enabled:
    • If the object of the latest version is not deletemarker, a new deletemarker is generated for the object.
    • If the object of the latest version is deletemarker and the object has this version only, the version will be deleted.
    • If the object of the latest version is deletemarker and the object has other versions, all versions of the object remain unchanged.
  • The multi-version of the bucket is suspended:
    • If the latest version is not null, deletemarker of a null version will be generated.
    • If the latest version is null, the null version will be overwritten by deletemarker of a new null version.

If the bucket versioning is Enabled or Suspended and the latest version of the object meets the transition rule:

  • If the latest version is deletemarker, this version will not transition to another storage class.
  • If the latest version is deletemarker and the object meets the transition conditions, this version will transition to another storage class.