HCP Tenant Management Help
You use the HTTP PUT method with the uploadId and partNumber query parameters to upload a part of a multipart upload. The bucket where you upload the part must be the same bucket as the one where the multipart upload was initiated.
To upload a part, you must be an authenticated user. You need to use the same user account as the account used in the request to initiate the multipart upload. Additionally, you need write permission for the bucket where you're uploading the part.
For a request to upload a part, the request body consists of the data in a specified file.
You use the uploadId query parameter to specify the upload ID of the multipart upload for which you're uploading the part. If the upload ID you specify doesn't match the upload ID of an in-progress multipart upload or isn't associated with the object specified in the request, HCP returns a 404 (Not Found) status code and does not upload the part.
When you upload a part, you use the partNumber query parameter to specify the part number of the data you're uploading. The part number must be an integer in the range 1 (one) through 10,000.
The parts of the data for an object are ordered, but the part numbers do not need to start at one and do not need to be consecutive numbers. For example, if you're uploading the data for an object in three parts, you could number the parts 1, 2, and 3, but you could also number them 2, 7, and 19.
You can upload the parts of a multipart upload in any order. However, in the request to complete the multipart upload, you need to list the parts in ascending numeric order.
You can upload multiple parts of a multipart upload concurrently.
If a request to upload a part includes any custom metadata (x-amz-meta-) headers, HCP returns a 400 (Bad Request) status code and does not upload the part.
HCP ignores ACL headers in requests to upload a part.
Part size
The parts you upload for a multipart upload can be any size up to and including five gigabytes. However, the minimum size for the parts you include in a complete multipart upload request, except the last part, is one megabyte. The last part can be smaller than one megabyte.
The maximum size for the object resulting from a multipart upload is five terabytes.
Replacing parts of a multipart upload
When you upload a part of a multipart upload, if you use a part number that was already used for a part in the same multipart upload, the new part replaces the part that was previously uploaded. The part that was replaced is automatically deleted.
You can replace a part multiple times. The part for which the upload finished last is the one that is used for the object created by the multipart upload.
ETags
When you upload a part of a multipart upload, HCP returns the ETag for the part in the ETag response header. The ETag is an identifier for the part data. In a request to complete a multipart upload, you need to specify the ETag along with the part number for each part you want to include in the resulting object.
Ensuring data integrity
When you upload a part of a multipart upload, you can use the Content-MD5 request header to ensure the integrity of the part data. The value you specify for this header must be the Base64-encoded MD5 hash of the original part data.
When you include the Content-MD5 header in a request to upload a part, HCP calculates the Base64-encoded MD5 hash of the data it receives and compares that to the header value. If the values don’t match, HCP returns a 400 (Bad Request) status code and does not upload the part.
Object encryption
The response headers returned in response to a successful request to upload a part of a multipart upload include x-amz-server-side-encryption, which indicates whether objects stored in HCP are encrypted. If stored objects are encrypted, the value of this header represents the encryption algorithm and key length HCP is using. If stored objects are not encrypted, the value of this header is None.
Saving network bandwidth
You can use the Expect request header in a request to upload a part to tell the application not to send the request body (the data) to HCP if the request headers are rejected. This prevents unnecessary network bandwidth usage.
Trademarks and Legal Disclaimer
© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.