Initiating a Multipart Upload¶
Functions¶
Before using this operation, make an API operation call to create a multipart upload task. The system will return a globally unique upload ID as the multipart upload identifier. You can use this ID to upload, assemble, and list parts. Create a multipart upload task does not affect the object that has the same name as object to be uploaded in multiple parts. You can create more than one multipart upload tasks for an object. This operation request can contain headers x-obs-acl, x-obs-meta-*, Content-Type, and Content-Encoding. The headers are recorded in the multipart upload metadata.
This operation supports server-side encryption.
WORM¶
If a bucket has WORM enabled, you can configure object-level retention policies when initiating multipart uploads. You can specify the x-obs-object-lock-mode and x-obs-object-lock-retain-until-date headers when you initiate a multipart upload to protect the object assembled. If you do not specify these two headers but have configured a default bucket-level WORM policy, this default policy automatically applies to the object newly assembled. You can also configure or update a WORM retention policy after the object is assembled.
Different from uploads with PUT and POST, a multipart upload only requires that the date specified in the x-obs-object-lock-retain-until-date header be no later than the initiation time, but does not have to be later than the completion time of the multipart upload. When the default bucket-level WORM policy is applied, the protection starts when the object parts are assembled and ends once the default bucket-level protection period expires. Before assembling the object parts uploaded, the multipart upload can be canceled and will not be affected by the WORM configuration.
Request Syntax¶
POST /ObjectName?uploads HTTP/1.1
Host: bucketname.obs.region.example.com
Date: date
Authorization: authorization
Request Parameters¶
This request uses parameters to specify a multipart upload. Table 1 describes the parameters.
Parameter | Type | Mandatory (Yes/No) | Description |
---|---|---|---|
uploads | String | Yes | Explanation: Indicates a multipart upload. Restrictions:
Value range: An empty string. Default value: None |
Request Headers¶
The request can use additional headers shown in Table 2.
Header | Type | Mandatory (Yes/No) | Description |
---|---|---|---|
x-obs-acl | String | No | Explanation: When initiating a multipart upload, you can add this header to set an object ACL. Example: x-obs-acl: public-read-write Restrictions: Use character strings. Value range:
Default value: private |
x-obs-grant-read | String | No | Explanation: When initiating a multipart upload, you can use this header to grant all users in a domain the permissions to read the object and obtain the object metadata. Example: x-obs-grant-read: ID=domainID. Restrictions: If multiple accounts are authorized, separate them with commas (,). Value range: None Default value: None |
x-obs-grant-read-acp | String | No | Explanation: When initiating a multipart upload, you can use this header to grant all users in a domain the permissions to obtain the object ACL. Example: x-obs-grant-read-acp: ID=domainID. Restrictions: If multiple accounts are authorized, separate them with commas (,). Value range: None Default value: None |
x-obs-grant-write-acp | String | No | Explanation: When initiating a multipart upload, you can use this header to grant all users in a domain the permissions to write the object ACL. Example: x-obs-grant-write-acp: ID=domainID Restrictions: If multiple accounts are authorized, separate them with commas (,). Value range: None Default value: None |
x-obs-grant-full-control | String | No | Explanation: When initiating a multipart upload, you can use this header to grant all users in a domain the following permissions: Permissions to read objects, obtain object metadata, obtain object ACLs, and write object ACLs. Example: x-obs-grant-full-control: ID=domainID. Restrictions: If multiple accounts are authorized, separate them with commas (,). Value range: None Default value: None |
x-obs-storage-class | String | No | Explanation: When initiating a multipart upload, you can add this header to specify the storage class for the object. Example: x-obs-storage-class: STANDARD Restrictions:
Value range:
Default value: By default, the storage class of the bucket is inherited. |
x-obs-website-redirect-location | String | No | Explanation: If the bucket is configured with website hosting, the request for obtaining the object can be redirected to another object in the bucket or an external URL. To another object in the same bucket: x-obs-website-redirect-location:/anotherPage.html To an external URL: x-obs-website-redirect-location:http://www.example.com/ OBS obtains the specified value from the header and stores it in the object metadata WebsiteRedirectLocation. Restrictions:
Default value: None |
x-obs-server-side-encryption | String | No. This header is required when SSE-KMS is used. | Explanation: Indicates that SSE-KMS is used. Example: x-obs-server-side-encryption: kms Restrictions: None Value range:
Default value: None |
x-obs-server-side-encryption-kms-key-id | String | No | Explanation: ID of a specified key used for SSE-KMS encryption. Restrictions: This header can only be used when you specify kms for the x-obs-server-side-encryption header. Default value: If you specify kms for encryption but do not specify a key ID, the default master key will be used. If there is not a default master key, OBS will create one and use it. |
x-obs-server-side-encryption-customer-algorithm | String | No. This header is required when SSE-C is used. | Explanation: The algorithm used for encryption. Example: x-obs-server-side-encryption-customer-algorithm: AES256 Restrictions:
Value range: AES256 Default value: None |
x-obs-server-side-encryption-customer-key | String | No. This header is required when SSE-C is used. | Explanation: The key used for encrypting an object. Example: x-obs-server-side-encryption-customer-key:K7QkYpBkM5+hca27fsNkUnNVaobncnLht/rCB2o/9Cw= Restrictions:
Value range: None Default value: None |
x-obs-server-side-encryption-customer-key-MD5 | String | No. This header is required when SSE-C is used. | Explanation: The MD5 value of the encryption key. The MD5 value is used to check whether any error occurs during the transmission of the key. Example: x-obs-server-side-encryption-customer-key-MD5:4XvB3tbNTN+tIEVa0/fGaQ== Restrictions:
Value range: Base64-encoded MD5 value of the key ID. Default value: None |
x-obs-expires | Integer | No | Explanation: Specifies when an object expires. It is measured in days. Once the object expires, it is automatically deleted. (The calculation starts from when the object was last modified). Example: x-obs-expires:3 Restrictions: This parameter can be configured only when uploading the object. It cannot be modified by calling a metadata modification API. Value range: An integer greater than or equal to 0, in days Default value: None |
x-obs-tagging | String | No | Explanation: An object's tag information in key-value pairs. Multiple tags can be added at the same time. Example: x-obs-tagging:TagA=A&TagB&TagC Restrictions:
Value range: None Default value: None |
x-obs-object-lock-mode | String | No, but required when x-obs-object-lock-retain-until-date is present. | Explanation: WORM mode to be applied to an object. Example: x-obs-object-lock-mode:COMPLIANCE Restrictions: This parameter must be used together with x-obs-object-lock-retain-until-date. Value range: Only COMPLIANCE (compliance mode) is supported. Default value: None |
x-obs-object-lock-retain-until-date | String | No, but required when x-obs-object-lock-mode is present. | Explanation: When the WORM policy of the object expires. Example: x-obs-object-lock-retain-until-date:2015-07-01T04:11:15Z Restrictions:
Value range: The time must be later than the current time. Default value: None |
x-obs-meta-* | String | No | Explanation: When initiating a multipart upload, you can use a header starting with x-obs-meta- in the HTTP request to define object metadata for easy management. The custom metadata will be returned in the response when you retrieve the object or query the object metadata. Example: x-obs-meta-test: test metadata Restrictions: This parameter can only be passed in HTTP request headers and cannot exceed 8 KB. Value range: None Default value: None |
For details about other common message headers, see Table 3.
Request Elements¶
This request involves no elements.
Response Syntax¶
HTTP/1.1 status_code
Date: date
Content-Length: length
Connection: status
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InitiateMultipartUploadResult xmlns="http://obs.region.example.com/doc/2015-06-30/">
<Bucket>BucketName</Bucket>
<Key>ObjectName</Key>
<UploadId>uploadID</UploadId>
</InitiateMultipartUploadResult>
Response Headers¶
The response to the request uses common headers. For details, see Table 1.
Header | Type | Description |
---|---|---|
x-obs-server-side-encryption | String | Explanation: The encryption method used by the server. Example: x-obs-server-side-encryption: kms Restrictions: This header is included in a response if SSE-KMS is used. Value range:
Default value: None |
x-obs-server-side-encryption-kms-key-id | String | Explanation: ID of a specified key used for SSE-KMS encryption. Restrictions: This header can only be used when you specify kms for the x-obs-server-side-encryption header. Default value: If you specify kms for encryption but do not specify a key ID, the default master key will be used. If there is not a default master key, OBS will create one and use it. |
x-obs-server-side-encryption-customer-algorithm | String | Explanation: The algorithm used for encryption. Example: x-obs-server-side-encryption-customer-algorithm: AES256 Restrictions: This header is included in a response if SSE-C is used for server-side encryption. Value range: AES256 Default value: None |
x-obs-server-side-encryption-customer-key-MD5 | String | Explanation: The MD5 value of the encryption key. Example: x-obs-server-side-encryption-customer-key-MD5:4XvB3tbNTN+tIEVa0/fGaQ== Restrictions: This header is included in a response if SSE-C is used for server-side encryption. Value range: Base64-encoded MD5 value of the key ID. Default value: None |
Response Elements¶
This response contains elements that indicate the multipart upload ID and the bucket and object names, which are used for uploading and assembling parts. Table 4 describes the elements.
Element | Type | Description |
---|---|---|
InitiateMultipartUploadResult | XML | Explanation: Container of a multipart upload task. Restrictions: None Value range: None Default value: None |
Bucket | String | Explanation: Indicates the bucket name in the multipart upload. Restrictions:
Value range: None Default value: None |
Key | String | Explanation: Name of the object in the multipart upload. An object is uniquely identified by an object name in a bucket. An object name is a complete path that does not contain the bucket name. Restrictions: None Value range: The value must contain 1 to 1,024 characters. Default value: None |
UploadId | String | Explanation: ID of the multipart upload, which is used to specify a multipart upload in uploading parts Restrictions: None Value range: The value must contain 1 to 32 characters. Default value: None |
Error Responses¶
If the AK or signature was invalid, OBS returns 403 Forbidden and the error code is AccessDenied.
If the bucket was not found, OBS returns 404 Not Found and the error code is NoSuchBucket.
If the user did not have the write permission for the specified bucket, OBS returns 403 Forbidden and the error code is AccessDenied.
Other errors are included in Table 2.
Sample Request: Initiating a Multipart Upload¶
POST /objectkey?uploads HTTP/1.1
Host: examplebucket.obs.region.example.com
Date: WED, 01 Jul 2015 05:14:52 GMT
Authorization: OBS AKIAIOSFODNN7EXAMPLE:VGhpcyBtZXNzYWdlIHNpZ25lZGGieSRlbHZpbmc=
Sample Response: Initiating a Multipart Upload¶
HTTP/1.1 200 OK
Server: OBS
x-obs-id-2: Weag1LuByRx9e6j5Onimru9pO4ZVKnJ2Qz7/C1NPcfTWAtRPfTaOFg==
x-obs-request-id: 996c76696e6727732072657175657374
Date: WED, 01 Jul 2015 05:14:52 GMT
Content-Length: 303
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InitiateMultipartUploadResult xmlns="http://obs.region.example.com/doc/2015-06-30/">
<Bucket>bucketname</Bucket>
<Key>objectkey</Key>
<UploadId>DCD2FC98B4F70000013DF578ACA318E7</UploadId>
</InitiateMultipartUploadResult>
Sample Request: Initiating a Multipart Upload (with the ACL Configured)¶
POST /objectkey?uploads HTTP/1.1
Host: examplebucket.obs.region.example.com
Date: WED, 01 Jul 2015 05:15:43 GMT
x-obs-grant-write-acp:ID=52f24s3593as5730ea4f722483579ai7,ID=a93fcas852f24s3596ea8366794f7224
Authorization: OBS AKIAIOSFODNN7EXAMPLE:VGhpcyBtZXNzYWdlIHNpZ25lZGGieSRlbHZpbmc=
Sample Response: Initiating a Multipart Upload (with the ACL Configured)¶
HTTP/1.1 200 OK
Server: OBS
x-obs-id-2: 32AAAQAAEAABAAAQAAEAABAAAQAAEAABCTnv+daB51p+IVhAvWN7s5rSKhcWqDFs
x-obs-request-id: BB78000001648457112DF37FDFADD7AD
Date: WED, 01 Jul 2015 05:15:43 GMT
Content-Length: 303
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InitiateMultipartUploadResult xmlns="http://obs.region.example.com/doc/2015-06-30/">
<Bucket>bucketname</Bucket>
<Key>objectkey</Key>
<UploadId>000001648453845DBB78F2340DD460D8</UploadId>
</InitiateMultipartUploadResult>