UploadPartCopy

API description

After calling InitiateMultipartUpload and getting the UploadId, use UploadPartCopy to copy the split object shard (Part). Specify the partNumber parameter to indicate each part's relative position in the object. The partNumber range is 1 - 10,000, allowing up to 10,000 parts per three-step copy, with a minimum of 1 part.

Description:

• Each Copy Part can copy up to 5 GB of data.
• The Metadata of the target object obtained from the three-step copy is not inherited from the source object. Users must re-upload it during CompleteMultipartUpload, or update it afterward by copying itself via [CopyObject API](BOS/API Reference/Object-Related Interface/Basic Operations/CopyObject.md).
• During UploadPartCopy, different parts can originate from different objects. The system imposes no restrictions on this.
• Currently support cross-region replication of files, meaning the source bucket where the copied file is located and the object bucket may not be in the same region (currently only supporting data copying from other regions to this region). The cross-region traffic generated from the cross-region replication of files will be charged. For the cross-region charging standards, see [Product Pricing](BOS/Product pricing/Product price/Pay-As-You-Go Charge Type.md).
• The three-step copy process does not apply to Append Object. Append Object can perform backup and metadata updates using standard copy methods.
• If the source object to be copied is subject to archive storage class, it is necessary to call the [RestoreObject API](BOS/API Reference/Object-Related Interface/Basic Operations/RestoreObject.md) first to restore the archive storage class objects.

Request

• Request syntax

  Plain Text Copy

  1PUT /<ObjectName>?uploadId=UploadId&partNumber=PartNumber HTTP/1.1
  2Host: <BucketName>.bj.bcebos.com
  3Date: <Date>
  4Authorization: <AuthorizationString>
  5Content-Type: text/plain
  6Content-Length: <ContentLength>
  7x-bce-copy-source: /SrcBucket/SrcObject
  8x-bce-copy-source-range: bytes=0-9

• Request headers

  header	Required or not	Description
  x-bce-copy-source	Yes	Copy the source file, e.g., /SrcBucket/SrcObject
  x-bce-copy-source-range	No	The byte range of the source file to be copied should use the format bytes=first-last. For instance, bytes=0-9 means the first 10 bytes will be copied. If this header is omitted, the entire file will be copied. Except for the last part, each part shard must be at least 100 KB and no more than 5 GB, with the total size of the object not exceeding 48.8 TB.
  x-bce-copy-source-if-match	No	If the etag value of the source file is the same as that provided in this header, it will be copied; otherwise, it will not be copied
  x-bce-copy-source-if-none-match	No	If the ETag value of the source file is not the same as that provided in this header, it will be copied; otherwise, it will not be copied
  x-bce-copy-source-if-unmodifed-since	No	If the source file is not modified after this header is provided, it will be copied; otherwise, it will not be copied
  x-bce-copy-source-if-modifed-since	No	If the source file is modified after this header is provided, it will be copied; otherwise, it will not be copied

  Plain Text Copy

  1> **Description:**
  2>
  3 > The format of each field is the same as the corresponding field in the [CopyObject API] (BOS/API Reference/Object Related API/Basic Operation/CopyObject.md).
  4 > Assume object content is "0123456789" with a length of 10. x-bce-copy-source-range is exemplified as follows:
  5>
  6 > -   range: 0-3, copy "0123";
  7 > -   range: 4-, copying from subscript 4 to the end of the file, i.e., copying "456789";
  8 > -   range: -4, copying the last 4 characters, i.e., "6789".

• Request parameters

Response

• Response element

1> **Note**
2>
3> 1.  UploadPartCopy returns the ETag for this part. The ETag is required during the third step of MultipartUpload. It is recommended that users verify the accuracy of the uploaded data using the ETag.
4> 2.  To maintain HTTP connections during the copying process, the HTTP response from the UploadPartCopy API may use Transfer-Encoding: Chunked mode.
5> 3.  If a server-side error occurs during the UploadPartCopy operation, the HTTP status code may still return 2XX, but the copy may fail. The result of the copy operation should be verified based on the JSON content in the HTTP body.

Example

• Request example

  Plain Text Copy

  1PUT /ObjectName?uploadId=a44cc9bab11cbd156984767aad637851&partNumber=1 HTTP/1.1
  2Host: BucketName.bj.bcebos.com
  3Date: <Date>
  4Authorization: <AuthorizationString>
  5Content-Type: text/plain
  6Content-Length: 0
  7x-bce-copy-source: /SrcBucket/SrcObject
  8x-bce-copy-source-range: bytes=0-9

• Response example

  Plain Text Copy

  1HTTP/1.1 200 OK
  2Date: Thu, 12 May 2016 09:14:32 GMT
  3Content-Type: application/json; charset=utf-8
  4Connection: keep-alive
  5Server: BceBos
  6x-bce-debug-id: MTAuNjMuMTIzLjI3OlRodSwgMTIgTWF5IDIwMTYgMTc6MTQ6MzIgQ1NUOjg3MjkzODMwMA==
  7x-bce-request-id: bb90cc9c-2b80-462c-87a4-095e610c9a2f
  8Transfer-Encoding: chunked
  9{   
  10    "lastModified":"2016-05-12T09:14:32Z",
  11    "eTag":"67b92a7c2a9b9c1809a6ae3295dcc127"
  12}

  Copy failed, to be judged according to the returned JSON

  Plain Text Copy

  1HTTP/1.1 200 OK
  2Date: Thu, 12 May 2016 09:14:32 GMT
  3Content-Type: application/json; charset=utf-8
  4Connection: keep-alive
  5Server: BceBos
  6x-bce-debug-id: MTAuNjMuMTIzLjI3OlRodSwgMTIgTWF5IDIwMTYgMTc6MTQ6MzIgQ1NUOjg3MjkzODMwMA==
  7x-bce-request-id: bb90cc9c-2b80-462c-87a4-095e610c9a2f
  8Transfer-Encoding: chunked
  9{
  10    "code":"InternalError",
  11    "message":"We encountered an internal error. Please try again.",
  12    "requestId":"52454655-5345-4420-4259-204e47494e58"
  13}