Put Bucket Lifecycle

Description

You can call this operation to create a lifecycle configuration for a bucket. If a lifecycle configuration has been created for the bucket, the new lifecycle configuration replaces the existing lifecycle configuration. To prevent a misoperation, take note of this point.
After you create a lifecycle configuration for the bucket, Kingsoft Cloud Standard Storage Service (KS3) automatically deletes objects to which lifecycle rules apply or converts the storage classes of the objects. — Permission description: To use this operation, you must be the owner of the bucket or have permission to perform the ks3:PutBucketLifecycle action.

Request

Request syntax

PUT /?lifecycle HTTP/1.1
Host: {BucketName}.{endpoint}
Date: {date}
Authorization: {SignatureValue}
Content-length: {length}
Content-MD5: {md5}

Lifecycle configuration in the request body

References:

• Endpoints and regions
• Request signature

Request parameters

No request parameter is used.

Request headers

Except for common request headers, this operation must include the Content-MD5 header, as described in the following table.

Request body

The following XML file describes a lifecycle configuration:

<LifecycleConfiguration>
  <Rule>
    <ID>id1</ID>
    <Filter>
      <Prefix>documents</Prefix>
    </Filter>
    <Expiration>
      <Date>2016-12-31T00:00:00.000Z</Date>
    </Expiration>
    <Status>Enabled</Status>
  </Rule>
  <Rule>
    <ID>id2</ID>
    <Filter>
      <Prefix>logs</Prefix>
    </Filter>
    <Expiration>
      <Days>130</Days>
    </Expiration>
    <Transition>
      <Days>10</Days>
      <StorageClass>STANDARD_IA</StorageClass>
    </Transition>
    <Transition>
      <Days>40</Days>
      <StorageClass>ARCHIVE</StorageClass>
    </Transition>
    <Status>Enabled</Status>
  </Rule>
  <Rule>
    <ID>id3</ID>
    <Filter>
      <Prefix>pic</Prefix>
    </Filter>
    <Status>Enabled</Status>
    <Expiration>
      <Date>2018-01-01T00:00:00.000Z</Date>
    </Expiration>
  </Rule>
  <Rule>
    <ID>id4</ID>
        <Filter>
         <And>
            <Prefix>123</Prefix>
            <Tag>
               <Key>age</Key>
               <Value>21</Value>
            </Tag>
            <Tag>
              <Key>name</Key>
              <Value>li</Value>
             </Tag>
         </And>
      </Filter>
  <Status>Enabled</Status>
  <Expiration>
    <Date>2021-01-01T00:00:00.000Z</Date>
  </Expiration>
        </Rule>

</LifecycleConfiguration>

The Rule node indicates a lifecycle rule and contains the following child nodes:

• Filter: Identifies objects to which the lifecycle rule applies. You can filter objects by key prefix, object tag, or a combination of both. You can specify only one key prefix in a single rule. If you define a lifecycle rule to delete objects and specify the log prefix to filter objects, KS3 deletes objects whose key starts with log1, log2, or log/2016. You can specify at most 10 object tags in a single rule.
• Status: Specifies whether to enable the lifecycle rule.
• Expiration: Specifies the date at which the object expires or the lifetime, in days, of the object.
• Transition: Specifies when the object transitions from one storage class to the specified storage class.

Note:

• Lifecycle rules take effect at 00:00 every day.
• A bucket can have up to 1,000 lifecycle rules.
• In a bucket, a rule ID uniquely identifies a rule. However, rules in different buckets can have the same rule ID. A rule ID is a random string that can be up to 255 UTF-8 characters in length.
• A bucket can have multiple rules. If you specify only prefixes to filter objects, the specified prefixes cannot overlap with each other. For example, the logs prefix does not overlap with the docs prefix. However, the logs prefix overlaps with the logs2016 prefix. If you specify tags and prefixes at the same time to filter objects, you can specify overlapping prefixes.
• The Days node specifies a relative time period. If the object was last modified at 15:05 on January 2, 2017 and the value of the Days node is 2, the object is deleted at the third midnight after the last modification time, which is 00:00 on January 5, 2017.
  Note: The modification operations include PUT, POST, and COPY.
• The Date node specifies an absolute time. The date must be in the ISO 8601 standard in the YYYY-MM-DDThh:mm:ss+08:00 format. Example: 2017-01-01T00:00:00+08:00. You must set hh:mm:ss to 00:00:00. Otherwise, an error is returned. When the lifecycle rule takes effect, the objects that were last modified at a date that is earlier than or equal to the specified date are deleted. If the specified date is earlier than or on the current day, the rule takes effect at 00:00 on the next day. If the specified date is later than the current day, the rule takes effect at 00:00 on the specified date.
• The StorgeClass node specifies the storage class to which the object transitions. Valid values: STANDARD_IA and ARCHIVE.

The following table describes the nodes in an XML file.

Notes:

• You must specify the ID node. The rule ID must be unique in an XML file.
• You must specify one of the Date node and Days node. The two nodes cannot be specified at the same time.
• You must specify the Status node.
• You must specify the Expiration node.
• The Filter node and Prefix node can be left empty. The prefixes that you specify in different rules cannot overlap with each other. For example, the log prefix overlaps with the log 2016 prefix.
• You can specify the Prefix node and Tag node at the same time. In a single rule, you can specify only one prefix but multiple tags.
• You can specify the required child nodes of the Rule node only once. For example, you can specify only one ID and state for a rule

Response headers

This operation involves only common response headers. For more information, see Common response headers.

Response body

No response body is returned.

Operation-specific errors

This operation does not return operation-specific errors.

Examples

Sample request

PUT /?lifecycle HTTP/1.1
Host: ks3-example.ks3-cn-beijing.ksyuncs.com
Date: Wed, 14 May 2014 02:11:21 GMT
Content-MD5: xxx 
Authorization: authorization string
Content-Length: yyy
Content-type: application/xml

<LifecycleConfiguration>
  <Rule>
    <ID>id1</ID>
    <Filter>
      <Prefix>documents</Prefix>
    </Filter>
    <Expiration>
      <Date>2016-12-31T00:00:00+08:00</Date>
    </Expiration>
    <Status>Enabled</Status>
  </Rule>
 <Rule>
    <ID>id2</ID>
    <Filter>
      <Prefix>logs</Prefix>
    </Filter>
    <Expiration>
      <Days>130</Days>
    </Expiration>
    <Transition>
      <Days>10</Days>
      <StorageClass>STANDARD_IA</StorageClass>
    </Transition>
    <Transition>
      <Days>40</Days>
      <StorageClass>ARCHIVE</StorageClass>
    </Transition>
    <Status>Enabled</Status>
  </Rule>
  <Rule>
    <ID>id3</ID>
     <Filter>
       <And>
          <Prefix>docs</Prefix>
          <Tag>
             <Key>age</Key>
             <Value>21</Value>
          </Tag>
          <Tag>
            <Key>name</Key>
            <Value>li</Value>
           </Tag>
       </And>
    </Filter>
    <Status>Enabled</Status>
    <Expiration>
      <Date>2021-01-01T00:00:00.000Z</Date>
    </Expiration>
  </Rule>
</LifecycleConfiguration>

The preceding XML file specifies three lifecycle rules in a bucket.

• The first rule specifies that KS3 deletes objects that were last modified before midnight of December 31, 2016. In addition, the key of the objects to be deleted must start with documents.
• The second rule specifies that KS3 deletes objects whose key starts with logs days after the objects were last modified.
• The third rule takes effect at 00:00 on January 1, 2021. When the rule takes effect, objects that were last modified before January 1, 2021 are deleted. In addition, the key of the objects to be deleted must start with docs, and the objects must be tagged with age:21 and name:li.

Sample response

HTTP/1.1 200 OK
Content-Length: 0
Date: Tue, 19 Jul 2017 09:14:23 GMT
Server: Tengine
x-kss-request-id: 54a47bda18ac4e6e91de369add54218***

Note: For more information, see Lifecycle management.