PutObject

Adds an object to a bucket.

We never add partial objects. If you receive a success response, this means that the entire object has been added to the bucket. If Tebi receives multiple write requests for the same object simultaneously, it overwrites all but the last object written.

To ensure that data is not corrupted traversing the network, use the Content-MD5 header. When you use this header, Tebi checks the object against the provided MD5 value. If they do not match, an error is returned. Additionally, you can calculate the MD5 while putting an object to Tebi and compare the returned ETag to the calculated MD5 value.

Server-Side Encryption

You can optionally request server-side encryption. With server-side encryption, Tebi encrypts your data as it writes it to disks and decrypts the data when you access it. You have the option to provide your own encryption key. For more information, see Server-Side Encryption.

Access Control List (ACL)-Specific Request Headers

You can use headers to grant ACL-based permissions. By default, all objects are private. Only the owner has full access control. When adding a new object, you can set public permission to the object so that anyone with a link can access it. These permissions are then added to the ACL on the object. For more information, see Access Control List (ACL) Overview.

Storage Class Options

By default, Tebi uses the STANDARD Storage Class to store newly created objects. You can change this in the bucket settings. For more information, see Storage Classes Overview.

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

The following operations are related to PutObject:

Request Syntax

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

The request uses the following URI parameters:

  • <BUCKET>: Bucket name to which the PUT action was initiated. Required.

  • <KEY>: Object key for which the PUT action was 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 what content encodings have been applied to the object and thus what 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: 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 this object (AES256).

  • x-amz-server-side-encryption-customer-algorithm: Specifies the algorithm to use to 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 and then 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 accepts body as binary data.

Response Syntax

1HTTP/1.1 200
2Content-Length: 0
3ETag: ETag
4x-amz-expiration: Expiration
5x-amz-server-side-encryption: ServerSideEncryption

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

The response returns the following HTTP headers:

  • Content-Length: Always 0.

  • ETag: Entity tag for the uploaded object.

  • x-amz-expiration: If the object expiration is configured, the response includes this header.

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

See Also

Refer here for more information.