Scsp Append; Introduction To Append - Dell DX6000 Application Manual

Chapter 10. SCSP APPEND
The following topics in this chapter discuss details about SCSP APPEND:
• Section 10.1, "Introduction to APPEND"
• Section 10.2, "Unnamed Object APPEND Details"

10.1. Introduction to APPEND

This section discusses general information about SCSP APPEND that applies to both named and
unnamed objects.
APPEND is used to append arbitrary content data onto the end of an existing named object or
unnamed anchor stream object, while maintaining the previously populated metadata and object
name or alias UUID. APPEND is not valid for immutable unnamed objects.
The original content data is copied by DX Storage from the original object and then the data
supplied in the request is appended to it. No whitespace or other characters are inserted by DX
Storage between the original and appended data.
The APPEND method returns a response only after all the data has been copied and the update is
complete. The syntax of an APPEND request is similar to that of PUT, and as with PUT, the object
name or UUID returned after a successful APPEND is identical to the one supplied in the request.
An example for a named object follows. APPEND for an unnamed object is the same except you
use the object's UUID (followed by the query argument alias=yes) instead of a name on the first
line of the command :
APPEND /mybucket/samplefile.txt HTTP/1.1
Host: cluster.example.com
Content-Length: 29
x-acme-meta-color: blue
x-acme-meta-weight: 42
lifepoint: [Sunday, 06-Nov-2010 08:49:37 GMT] reps=3, deletable=no
lifepoint: [] delete
Status: Approved
The Content-length header must be supplied and it must be the correct length of the content
data to be appended. The Content-length header in the object is adjusted to reflect the actual
length of the original data plus the appended data. All other headers stored with the object are
copied without change to the newly updated stream. That means the x-acme-meta-* and lifepoint
headers in the preceding example are ignored.
If the client provides a Content-MD5 header with the APPEND request, DX Storage computes the
digest of the content data plus the appended data and compares it with the provided MD5 hash.
This assumes the client either has access to the original data or maintains a running digest to which
appended data is added before each APPEND request.
If a Content-MD5 header was persisted with the original stream, it is removed when new data is
appended to the stream. Any new, correct Content-MD5 supplied with an append is persisted with
the new revision and returned on any subsequent GET or HEAD.
Range headers are incompatible with the APPEND method. Including a Range header with an
APPEND request results in a 400 (Bad request) error response. Other aspects of the APPEND
method, including response codes, are the same as PUT.
Copyright © 2010 Caringo, Inc.
All rights reserved 37
Version 5.0
December 2010