| Table of Contents | ||
|---|---|---|
|
When the initiate request is complete, you are ready to upload the individual parts of a larger object. Swarm allows any number of parts in a multipart upload. (v9.1)
...
When a part is successfully uploaded, it is stored as an immutable object whose Content-UUID is returned in the request response. Your client application must keep track of the part number used for the upload and the Content-UUID Swarm assigned it when it was stored in order to eventually complete the multipart upload, as described below.
| Info | |
|---|---|
| title | Parts are unnamedEven if the initiated object is named, each part is an immutable object that will return a Content-UUID, even though a POST on a named object does not ordinarily return that header. The parts are tenanted in the same domain as the destination object, but parts are unnamed, so they cannot reside in buckets. |
Using object part numbers
...
To upload each part, you must include three things:
the object name or UUID (or Content-UUID, for immutable objects) that is returned by the initiate request
the upload ID returned from the initiate request
a unique part number for each part that is uploaded
| Code Block | ||
|---|---|---|
| ||
POST /ObjectNameorUUID?partNumber=PartNumber&uploadId=UploadId HTTP/1.1 Host: cluster.example.com User-Agent: Swarm Client/0.1 Content-Length: 43402 Expect: 100-continue [ content ] |
...
If the required parts currently exist in your storage cluster, you can create a POST request that uses the content from existing objects. When the part copy request is completed, Swarm creates an EC copy of the object for the multipart write. If the source object does not exist or cannot be read from the specified range, the request will fail. This process leaves the source and destination versions unrelated to each other.
| Info |
|---|
Content GatewayWhen going through Gateway, the user who is making the "PUT with copy" request must have read access to the source object. |
...
| Code Block | ||
|---|---|---|
| ||
POST /ObjectNameorUUID?partNumber=PartNumber&uploadId=UploadId HTTP/1.1 x-castor-copy-source: uuid/name x-castor-copy-source-domain: domain_name |
| Info |
|---|
Response HeadersWhenever the x-castor-copy-source header is used, the result code for the operation (which always responds with chunked encoding) is in the trailing header Castor-System-Result. See "Response Headers for Multipart Writes" in Completing the Multipart Write. |
-copy-source- headers
The following headers in the POST request for part uploads are optional, except for the first. If you include them, they perform the same filtering as the regular headers of those names (range, if-match, etc.), performed against the source object being copied.
| Info |
|---|
NoteError responses on conditional headers come back immediately, in place of a 202 (Accepted for processing) response. Condition failures (such as the ETags not matching) are reported in the initial HTTP response, not the castor-system-result header. |
Type | Header | Notes |
|---|---|---|
Source | x-castor-copy-source | Required. Must be a valid name or UUID. |
Domain | x-castor-copy-source-domain | Required (unless untenanted) |
Range | x-castor-copy-source-range: bytes=first-last | If the range values are out of bounds for the data, the request returns 416 (Range Not Satisfiable). Tip: To copy from a start range to the end of the object, omit the end range. (v11.1) |
Conditional | x-castor-copy-source-if-match: "<ETag>" | The ETag must be enclosed in quotes. |
x-castor-copy-source-if-unmodified-since: <timestamp> | Uses the format of the standard HTTP last-modified header. |
Validating the uploaded parts
...