Description
The Upload Part API is used to upload an object to COS in parts. Up to 10,000 parts are supported, each part is 1 MB to 5 GB, and the last part can be less than 1 MB.
Notes
- Multipart upload requires initialization first via the Initiate Multipart Upload interface, which returns an uploadId to uniquely identify the upload.
- Each Upload Part request must include the partNumber and uploadId, where partNumber represents the part number and supports out-of-order uploading.
- When the uploaded uploadId and partNumber are the same, the later part will overwrite the earlier part. When uploadId does not exist, a 404 error, NoSuchUpload, is returned.
Request
Syntax example:
PUT /ObjectName?partNumber=PartNumber&uploadId=UploadId HTTP/1.1
Host: <BucketName-APPID>.<Endpoint>
Date: GMT Date
Content-Length: Size
Authorization: Auth String
Note:
Authorization: Auth String (See Request Signature for details.)
Request Line
PUT /ObjectName?partNumber=PartNumber&uploadId=UploadId HTTP/1.1
This API accepts PUT requests.
Request Parameters
An example request line containing all request parameters:
PUT /ObjectName?partNumber=PartNumber&uploadId=UploadId HTTP/1.1
The specific contents are as follows:
| Parameter Name | Description | Type | Required |
|---|---|---|---|
| partNumber | Identifies the number of the parts being uploaded in this multipart upload. | String | Yes |
| uploadId | The ID that identifies this multipart upload. When you use the Initiate Multipart Upload API to initiate multipart upload, you will get an uploadId, which not only uniquely identifies the multipart data, but also identifies the relative position of the multipart data in the entire file. |
String | Yes |
Request Header
Common Headers
This request uses common request headers. For details, see Common Request Headers.
Non-common Headers
Required Headers
This request operation requires the mandatory use of request headers, with specific contents as follows:
| Name | Description | Type | Required |
|---|---|---|---|
| Content-Length | HTTP response length in bytes as defined in RFC 2616. | String | Yes |
Recommended Headers
This request operation recommends the use of recommended headers in the request, with specific contents as follows:
| Name | Description | Type | Required |
|---|---|---|---|
| Expect | HTTP response length in bytes as defined in RFC 2616. | String | No |
| Content-MD5 | Base64-encoded 128-bit content MD5 checksum as defined in RFC 1864. This header is used to verify whether the file content has changed. | String | No |
Request Body
The request operation's request body is empty.
Response
Response Headers
Common Response Headers
This response uses common response headers. For details, see Public Response Header.
Response Body
The response body of this response is empty.
Practical Case
Request
PUT /ObjectName?partNumber=1&uploadId=1484727270323ddb949d528c629235314a9ead80f0ba5d993a3d76b460e6a9cceb9633b08e HTTP/1.1
Host: <BucketName-APPID>.<Endpoint>
Date: Wed，18 Jan 2017 16:17:03 GMT
Authorization: q-sign-algorithm=sha1&q-ak=AKIDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&q-sign-time=1484727403;32557623403&q-key-time=1484727403;32557623403&q-header-list=host&q-url-param-list=partNumber;uploadId&q-signature=bfc54518ca8fc31b3ea287f1ed2a0dd8c8e88a1d
Content-Length: 10485760
[Object]
Response
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 0
Connection: keep-alive
Date: Wed，18 Jan 2017 16:17:03 GMT
Etag: "e1e5b4965bc7d30880ed6d226f78a5390f1c09fc"
x-cos-request-id: NTg3ZjI0NzlfOWIxZjRlXzZmNGJfMWYy