Storing an object

You use the HTTP PUT method to store an object in a bucket. To store an object, you need write permission for the bucket.

For a request to store an object, the request body consists of the data in a specified file. This data becomes the object content.

When you store an object, you specify a name for it. The object name does not need to be the same as the name of the file containing the original data. For information on naming objects, see Object names.

If versioning is enabled and you try to store an object with the same name as an existing object, HCP creates a new version of the object. If versioning is disabled and you try to store an object with the same name as an existing object, HCP returns a 409 (Conflict) status code and does not store the object. For information on versioning, see Versioning.

You can add custom metadata to an object in the same request as you use to store the object. To do this, you use x-amz-meta- headers. For information on custom metadata, see Custom metadata.

You can specify an ACL for an object in the same request as you use to store the object. To do this, you need to use ACL headers. You cannot use an ACL request body when storing an object. For information on ACLs, see Access control lists.

If the ACL you specify in a request to store an object is invalid, HCP returns a 400 (Bad Request) or 501 (Not Implemented) status code and does not store the object.

If you’re an authenticated user, when you store an object, you become the object owner. If you’re accessing the bucket anonymously, the new object has no owner. For information on object ownership, see Object owners.

ETags

When you store an object, HCP returns the ETag for the object in the ETag response header. An ETag is an identifier for the content of an object. ETags are useful for making object-level operations conditional based on the object content. Operations that can be made conditional are checking the Checking the existence of an object or folder, Copying an object, and Retrieving an object.

Ensuring object integrity

When you store an object, you can use the Content-MD5 request header to ensure the integrity of the object data. The value you specify for this header must be the Base64-encoded MD5 hash of the original file data.

When you include the Content-MD5 header in a request to store an object, 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 store the object.

Object encryption

When you store an object, you can use the x-amz-server-side-encryption request header to determine whether objects stored in HCP are encrypted. If stored objects are encrypted, the response headers include x-amz-server-side-encryption with a value representing the encryption algorithm and key length HCP is using. If stored objects are not encrypted, the value of the x-amz-server-side-encryption response header is None.

Saving network bandwidth

You can use the Expect request header in a request to store an object 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.

Trademark and LegalDisclaimer

© 2015 Hitachi Data Systems Corporation. All rights reserved.