Static large objects

To create a static large object, divide your content into pieces and create (upload) a segment object to contain each piece.

You must record the ETag response header that the PUT operation returns. Alternatively, you can calculate the MD5 checksum of the segment prior to uploading and include this in the ETag request header. This ensures that the upload cannot corrupt your data.

List the name of each segment object along with its size and MD5 checksum in order.

Create a manifest object. Include the ?multipart-manifest=put query string at the end of the manifest object name to indicate that this is a manifest object.

The body of the PUT request on the manifest object comprises a json list, where each element contains the following attributes:

  • path. The container and object name in the format: {container-name}/{object-name}

  • etag. The MD5 checksum of the content of the segment object. This value must match the ETag of that object.

  • size_bytes. The size of the segment object. This value must match the Content-Length of that object.

 

Example 1.3. Static large object manifest list

This example shows three segment objects. You can use several containers and the object names do not have to conform to a specific pattern, in contrast to dynamic large objects.

[
   {
      "path":"mycontainer/objseg1",
      "etag":"0228c7926b8b642dfb29554cd1f00963",
      "size_bytes":1468006
   },
   {
      "path":"mycontainer/pseudodir/seg-obj2",
      "etag":"5bfc9ea51a00b790717eeb934fb77b9b",
      "size_bytes":1572864
   },
   {
      "path":"other-container/seg-final",
      "etag":"b9c3da507d2557c1ddc51f27c54bae51",
      "size_bytes":256
   }
]

The Content-Length request header must contain the length of the json content—not the length of the segment objects. However, after the PUT operation completes, the Content-Length metadata is set to the total length of all the object segments. A similar situation applies to the ETag. If used in the PUT operation, it must contain the MD5 checksum of the json content. The ETag metadata value is then set to be the MD5 checksum of the concatenated ETag values of the object segments. You can also set the Content-Type request header and custom object metadata.

When the PUT operation sees the ?multipart-manifest=put query parameter, it reads the request body and verifies that each segment object exists and that the sizes and ETags match. If there is a mismatch, the PUToperation fails.

If everything matches, the manifest object is created. The X-Static-Large-Object metadata is set to true indicating that this is a static object manifest.

Normally when you perform a GET operation on the manifest object, the response body contains the concatenated content of the segment objects. To download the manifest list, use the ?multipart-manifest=get query parameter. The resulting list is not formatted the same as the manifest you originally used in the PUT operation.

If you use the DELETE operation on a manifest object, the manifest object is deleted. The segment objects are not affected. However, if you add the ?multipart-manifest=delete query parameter, the segment objects are deleted and if all are successfully deleted, the manifest object is also deleted.

To change the manifest, use a PUT operation with the ?multipart-manifest=put query parameter. This request creates a manifest object. You can also update the object metadata in the usual way.

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page

loading table of contents...