CreateMultipartUpload

Initiates a multipart upload and returns an upload ID.

This upload ID is used to associate all parts in the specific multipart upload. Specify this upload ID in each of your subsequent upload part requests (see UploadPart). Additionally, include this upload ID in the final request to either complete or abort the multipart upload request.

If you have configured a lifecycle rule to abort incomplete multipart uploads, the upload must complete within the number of days specified in the bucket lifecycle configuration. Otherwise, the incomplete multipart upload becomes eligible for an abort action and is eventually aborted.

You can optionally request server-side encryption. For server-side encryption, Tebi encrypts your data as it writes it to disks in its data centers, and decrypts the data when you access it. You can provide your own encryption key, or let Tebi to manage it for you.

If you choose to provide your own encryption key, the request headers you provide in UploadPart request must match the headers you used in the request to initiate the upload by using CreateMultipartUpload.

You must have Upload ACL to be able to call this action.

The following operations are related to CreateMultipartUpload:

Request Syntax

 1POST /<KEY>?uploads HTTP/1.1
 2Host: <BUCKET>.s3.tebi.io
 3Cache-Control: CacheControl
 4Content-Disposition: ContentDisposition
 5Content-Encoding: ContentEncoding
 6Content-Language: ContentLanguage
 7Content-Type: ContentType
 8Expires: Expires
 9x-amz-acl: ACL
10x-amz-storage-class: StorageClass
11x-amz-website-redirect-location: WebsiteRedirectLocation
12x-amz-server-side-encryption: ServerSideEncryption
13x-amz-server-side-encryption-customer-algorithm: SSECustomerAlgorithm
14x-amz-server-side-encryption-customer-key: SSECustomerKey
15x-amz-server-side-encryption-customer-key-MD5: SSECustomerKeyMD5

The request uses the following URI parameters:

  • <BUCKET>: Name of the bucket to which to initiate the upload. Required.

  • <KEY>: Object key for which the multipart upload is to be initiated. Required.

The request uses the following headers:

  • Cache-Control: Can be used to specify caching behavior along the request/reply chain.

  • Content-Disposition: Specifies presentational information for the object.

  • Content-Encoding: Specifies which content encodings have been applied to the object and thus which decoding mechanisms must be applied to obtain the media-type referenced by the Content-Type header field.

  • Content-Language: Language the content is in.

  • Content-Length: Size of the body in bytes. This parameter is useful when the size of the body cannot be determined automatically.

  • Content-MD5: 128-bit MD5 digest encoded as 32-characters HEX or base64-encoded 128-bit MD5 digest of the message (without the headers) according to RFC 1864. This header can be used as a message integrity check to verify that the data is the same data that was originally sent. Although it is optional, we recommend using the Content-MD5 mechanism as an end-to-end integrity check.

  • Content-Type: Standard MIME type describing the format of the contents.

  • Expires: Date and time at which the object is no longer cacheable.

  • x-amz-acl: The canned ACL to apply to the object. Valid Values: private | public-read | public-read-write.

  • x-amz-storage-class: User-defined storage class. For more information, see Storage Classes Overview.

  • x-amz-website-redirect-location: If the bucket is configured as a website, this redirects requests for the object to another object in the same bucket, or to an external URL.

  • x-amz-server-side-encryption: Server-side encryption algorithm used when storing the object (AES256).

  • x-amz-server-side-encryption-customer-algorithm: Specifies the algorithm to use when encrypting the object (AES256).

  • x-amz-server-side-encryption-customer-key: Specifies the customer-provided encryption key for Tebi to use in encrypting data. This value is used to store the object before it is discarded – Tebi does not store the encryption key. The key must be appropriate for use with the algorithm specified in the x-amz-server-side-encryption-customer-algorithm header.

  • x-amz-server-side-encryption-customer-key-MD5: Specifies the 128-bit MD5 digest of the encryption key according to RFC 1321. Tebi uses this header for a message integrity check to ensure that the encryption key was transmitted without error.

The request does not have a request body.

Response Syntax

 1HTTP/1.1 200
 2Content-Type: application/xml
 3Content-Length: ContentLength
 4ETag: ETag
 5x-amz-server-side-encryption: ServerSideEncryption
 6x-amz-abort-date: AbortDate
 7x-amz-abort-rule-id: AbortRuleId
 8
 9<?xml version="1.0" encoding="UTF-8"?>
10<InitiateMultipartUploadResult>
11    <Bucket>string</Bucket>
12    <Key>string</Key>
13    <UploadId>string</UploadId>
14</InitiateMultipartUploadResult>

If the action is successful, the service sends back an HTTP 200 response.

The response returns the following HTTP headers:

  • x-amz-server-side-encryption: Server-side encryption algorithm used when storing this object (AES256).

  • x-amz-abort-date: If the bucket has a lifecycle rule configured with an action to abort incomplete multipart uploads and the prefix in the lifecycle rule matches the object name in the request, the response includes this header. The header indicates when the initiated multipart upload becomes eligible for an abort operation.

  • x-amz-abort-rule-id: This header is returned along with the x-amz-abort-date header. It identifies the applicable lifecycle configuration rule that defines the action to abort incomplete multipart uploads.

The following data is returned in XML format by the service:

  • InitiateMultipartUploadResult: Root level tag for the InitiateMultipartUploadResult parameters.

  • Bucket: Name of the bucket to which the multipart upload was initiated.

  • Key: Object key for which the multipart upload was initiated.

  • UploadId: ID for the initiated multipart upload.

See Also

Refer here for more information.