Complete Multipart Upload

Last updated:2021-04-28 10:59:28


This operation will complete the block upload task before the object assembly.

After starting a block upload task, the user will use the Upload Parts interface to upload all blocks. After successfully uploading all related blocks, the user needs to call this interface to complete the block upload. After receiving the completion request, KS3 will assemble all the blocks according to the block sequence number to create a new object. In the user’s task completion request, the user needs to provide a block list. Because KS3 will connect all blocks according to the list, the user is required to ensure that all blocks have been uploaded. For each block in the block list, the user needs to add the block number and the ETag header of the object when uploading the block, and KS3 will reply to complete the response after the block is uploaded.

Please note that if the Complete Multipart Upload request fails, the user application should be able to retry the operation.



POST /{ObjectKey}?uploadId={UploadId} HTTP/1.1
Host: {BucketName}.{endpoint}
Date: {Date}
Content-Length: {Size}
Authorization: {SignatureValue}



Request Parameters

The request does not use the request parameter.

Request Headers

This request uses only the common request headers. For more information, please click Public Request Headers

Request Elements

Name Description Required
CompleteMultipartUpload Request information container.
Ancestors: None
Type: Container
Child Node: One or more Part elements
Part A specific uploaded block information container.
Ancestors: CompleteMultipartUpload
Type: Container
Child Node: PartNumber, ETag
PartNumber The block serial number used to identify the block.
Ancestors: Part
Type: Integer
ETag The entity label returned after the block is uploaded.
Ancestors: Part
Type: String


Response Headers

This interface uses common response headers. For more information, please click Public Response Headers

Name Description
x-kss-server-side-encryption If server-side encryption is used to store object, the response will contain the header, and the value is the encryption algorithm used.
x-kss-server-side-encryption-customer-algorithm If the server uses the encryption key provided by the user for encryption, the response will include the header to confirm the decryption algorithm used when the request is decrypted.
Valid Value:AES256

Response Elements

Name Description
CompleteMultipartUploadResult Container for response information.
Type: Container
Child Node: Location, Bucket, Key, ETag
Ancestors: None
Location The URI used to identify the newly created object.
Type: URI
Ancestors: CompleteMultipartUploadResult
Bucket The name of the space containing the newly created object。
Type: String
Key The object key of the newly created object.
Type: String
ETag The 32-bit hexadecimal string used to identify the content of Object. Different content of Object corresponds to different ETag. For Object created by Put Object or Post Object request, ETag value is the MD5 value of its content. For Object created by block upload method, ETag value is the MD5 value of each block after string splicing. The ETag value can be used to check whether the Object content has changed.
Type: String
Ancestors: CompleteMultipartUploadResult

Special Errors

Error Code Description HTTP Status Code
EntityTooSmall The block size to be uploaded by the user is smaller than the minimum allowed by the object. Except for the last block, each block shall be at least 5MB. When the total size of the file is within 5M, each block can be at least 100k except the last block. 400 Bad Request
InvalidPart One or more of the specified blocks were not found. The block may not have been uploaded, or it may have been uploaded but the entity tags do not match. 400 Bad Request
InvalidPartOrder The chunked list is not in ascending order. The number of blocks must be specified in sequence. 400 Bad Request
NoSuchUpload The specified chunk upload task does not exist. It may be that the upload ID is invalid, or the block upload task has been completed or abandoned. 404 Not Found


Sample Request

POST /my-viedo.rm ?uploadId=1aa9cfad5e2e405c8f27965feb8b60cc HTTP/1.1
Date: Mon, 1 Nov 2010 20:34:56 GMT
Content-Length: 391
Authorization: authorization string


Sample Response

HTTP/1.1 200 OK
Date: Mon, 1 Nov 2010 20:34:56 GMT
Connection: close
Server: Tengine

<?xml version="1.0" encoding="UTF-8"?>
<CompleteMultipartUploadResult xmlns="">

Interface Detail Analysis

  • Except for the last block, each block shall be at least 5MB. When the total size of the file is within 5M, each block can be at least 100k except the last block.
  • The list of parts submitted by users must be in ascending order.
  • When the operation is completed, the corresponding UploadId will be invalid
  • The same Object can have different upload IDS at the same time. When an Upload ID is completed, other upload IDs of the object are not affected.
  • Each part in the submitted part list must exist. Otherwise, InvalidPartOrder will be reported

Did you find the above information helpful?

Mostly Unhelpful
A little helpful
Very helpful

What might be the problems?

  • Insufficient
  • Outdated
  • Unclear or awkward
  • Redundant or clumsy
  • Lack of context for the complex system or functionality

More suggestions


Please give us your feedback.


Thank you for your feedback.