v1.0 supplied as
- the path. Additionally, two headers are required,
- X-Auth-User and X-Auth-Key
- with values for the username and API Access Key
- respectively.X-Auth-Token.
- Clients obtain this token, along with the Cloud Servers
- API URL, by first using an authentication service and
- supplying a valid username and API access key.X-Auth-User x-header.
- X-Auth-Key
- x-header.X-Storage-Url and
- X-Auth-Token headers. Any 2xx
- response is a good response. For example, a 202
- response means the request has been accepted. Also,
- additional X- headers may be returned.
- These additional headers are related to other
- Rackspace services and can be ignored. An HTTP status
- of 401 (Unauthorized) is returned upon authentication
- failure. All subsequent container/object operations
- against OpenStack Object Storage should be made
- against the URI specified in
- X-Storage-Url and must include the
- X-Auth-Token header.X-Storage-Url will need to be
- parsed and used in the connection and request line of
- all subsequent requests against Object Storage. In the
- example response above, users connecting to OpenStack
- Object Storage would send most container/object
- requests with a host header of
- storage.swiftdrive.com and the
- request line's version and account as
- /v1/CF_xer7_34. Note that
- authentication tokens are valid for a 24 hour period
- for many authentication configurations.X-Auth-Token. Clients obtain this
- token, along with the OpenStack Object Storage URLs, by
- first using the Authentication service and supplying a
- valid Username and API Access Key.X-Storage-Url is used for managing the
- data stored in the system. Example operations are creating
- containers and uploading objects.
- X-Storage-Url can be used to create a
- container or upload an
- object.X-Storage-Url HTTP header
- obtained during successful authentication.X-Auth-Token header. The following
- example demonstrates how to use cURL to obtain the
- authorization token and the URL of the storage
- system.-X switch to specify the correct HTTP
- method and the -i to dump the HTTP response
- headers to terminal output (stdout).manifest.json with the following
- content:?multipart-manifest=put query
- string.X-Container-Meta-Web-Error to
- error.html, 401 errors will display the
- page 401error.html. Similarly, 404 errors
- will display 404error.html. You must have
- both of these pages created in your container when you set
- the X-Container-Meta-Web-Error metadata, or
- your site will display generic error pages.X-Container-Meta-Web-Error metadata
- once for your entire static website.| Option | +Description | +
|---|---|
| + + | +
+ |
+
| + + | +
+ |
+
| + + | +
+ |
+
| + + | +
+ |
+
| + + | +
+ |
+
| + + | +
+ |
+
https://23.253.72.207/v1/my_account.X-Delete-At header is
+ assigned a UNIX Epoch timestamp in integer form for Mon,
+ 11 Jun 2012 15:38:25 GMT. Use http://www.epochconverter.com/ for example
+ timestamps and a batch converter.X-Delete-After header
+ to a value in seconds that is equivalent to 10 days. After
+ this time, the object expires.delimiter query parameter. this examples show
+ you how to use pseudo-hierarchical folders and
+ directories.backups. Within that container, the
+ objects are organized in a pseudo-directory called
+ photos. Keep in mind that the container
+ name is not displayed in the example, but that it is a
+ part of the object URLs. For instance, the URL of the
+ picture me.jpg is
+ delimiter or
+ prefix.delimiter with pseudo-directories, use
+ the parameter slash (photos/ displays. Keep in mind that the
+ returned values from a slash delimiter query
+ are not real objects. They have a content-type of
+ prefix and delimiter
+ parameters to view the objects inside a pseudo-directory,
+ including further nested pseudo-directories.prefix parameter coupled with the
+ delimiter parameter. In this sample
+ output, there is a pseudo-directory called
+ dogs within the pseudo-directory
+ animals. To navigate directly to the
+ files contained within dogs, enter the
+ following command:format=format
+ query parameterjson or
+ xml.text/plain. Plain text
+ response format. The default.application/json. JSON
+ data serialization response
+ format.application/xml or
+ text/xml. XML data
+ serialization response format.X-NewestX-newest header to
- True in HEAD and GET requests to have
- Object Storage return the latest version of the container.
- If set to True, Object Storage queries all
- replicas to return the most recent one. Without this header,
- Object Storage responds faster after it finds one valid replica.
- Because setting this header to True is more
- expensive for the back end, use it only when it is
- absolutely needed.
- limitmarkerend_markerprefixformatjson or
- xml to return the respective
- serialized response.delimiterpathformat=xml or
- format=json argument is appended to
- the storage account URL, the service will serve
- extended object information serialized in the chosen
- format. Other than the ?format=xml|json
- parameter, it will return the same status/errors
- codes. The sample responses below are formatted for
- readability.end_marker we can limit
- the result set to object names less than the given
- value.delimiter query parameter.
- See the below examples for an illustration.backups. Within that
- container, the objects are organized in a
- pseudo-directory called photos. Keep
- in mind that the container name is not displayed
- in the example, but that it is a part of the
- object URLs. For instance, the URL of the picture
- me.jpg is
- delimiter or prefix.delimiter with
- pseudo-directories, use the parameter slash
- (photos/ displays. Keep
- in mind that the returned values from a slash
- delimiter query are not real objects.
- They have a content-type of
- prefix parameter with the
- delimiter parameter to view the
- objects inside a pseudo-directory, including
- further nested pseudo-directories.prefix parameter coupled
- with the delimiter parameter. In the
- sample output below, there is a pseudo-directory
- called dogs within the
- pseudo-directory animals. In order to
- navigate directly to the files contained within
- dogs, enter the below command.X-Container-Meta- prefix.X-Container-Meta- prefix in the header,
- your &GET;/&HEAD; request responses carry the metadata
- prefix from the container in subsequent requests.X-Container-Meta- prefix in the header,
- your &GET;/&HEAD; request responses carry the metadata
- prefix from the container in subsequent requests.X-Container-Object-Count and
- X-Container-Bytes-Used headers
- respectively.X-Container-Meta-.X-Container-Meta-Book:.X-Remove-Container-Meta-Book: x. The
- X-NewestX-newest header to
- True in HEAD and GET requests to
- have Object Storage return the latest version of
- the object. If set to True, Object
- Storage queries all replicas to return the most
- recent one. Without this header, Object Storage
- responds faster after it finds one valid replica.
- Because setting this header to True
- is more expensive for the back end, use it only
- when it is absolutely needed.Range header to fetch
- portions of data by using one or more range
- specifications. To specify many ranges, separate the range
- specifications with a comma.Range: bytes=-5Range:
- bytes=10-14Range:
- bytes=10-14,-5Content-Type of the
- response is then
- multipart/byteranges.Range:
- bytes=4-6Range:
- bytes=2-2Range: bytes=6-Range:
- bytes=1-3,2-5Content-Type of the
- response is then
- multipart/byteranges.X-Delete-At or
- X-Delete-After headers during an object
- &PUT; operation. When Object Storage detects one of these
- headers, the system automatically stops serving that
- object at the specified time and shortly after the
- expiration date, it removes the object from the storage
- system.X-Object-Meta-
- prefix, or arbitrary headers set with the
- Content-Length or
- Content-Type header in the request. If
- the MD5 checksum of the data written to the storage system
- does NOT match the (optionally) supplied ETag value, a 422
- (Unprocessable Entity) response is returned.Transfer-Encoding: chunked and not
- using a Content-Length header. A good use
- of this feature would be doing a DB dump, piping the
- output through gzip, then piping the data directly
- into OpenStack Object Storage without having to buffer
- the data to disk to compute the file size. If users
- attempt to upload more than 5GB with this method, the
- server will close the TCP/IP connection after 5GB and
- purge the customer data from the system. Users must
- take responsibility for ensuring the data they
- transfer will be less than 5GB or for splitting it
- into 5GB chunks, each in its own storage object. If
- you have files that are larger than 5GB see X-Object-Manifest metadata. The
- value of this is
- <container>/<prefix>, where
- <container> is the name of the
- container where the segment objects are stored and
- <prefix> is a string that all
- the segment objects have in common.| Feature | -Static Large Object | -Dynamic Large Object | -
|---|---|---|
| End-to-end integrity | -Assured. The list of segments includes the MD5 - checksum (ETag) of each segment. You cannot - upload the manifest object if the ETag in the - list differs from the segment object already - uploaded. If a segment is somehow lost, an - attempt to download the manifest object will - result in an error. | -Not guaranteed. The eventual consistency model - means that although you may have uploaded a - segment object, it may not appear in the - container listing until later. If you download - the manifest before it appears in the - container, it will not form part of the - content returned in response to a &GET; - request. | -
| Upload order | -The segment objects must be uploaded before - the manifest object. | -You can upload manifest and segment objects in - any order. You are recommended to upload the - manifest object after the segments in case a - premature download of the manifest occurs. - However, this is not enforced. | -
| Removal or addition of segment objects | -You cannot add or remove segment objects from - the manifest. However, you can create a - completely new manifest object of the same - name with a different manifest list. | -You can upload new segment objects or remove
- existing segments --- the names must simply
- match the <prefix> supplied in
- X-Object-Manifest. |
-
| Segment object size and number | -Segment objects must be at least 1MB in size - (by default). The final segment object can be - any size. At most 1000 segments are supported - (by default). | -Segment objects can be of any size. | -
| Segment object container name | -The manifest list includes the container name - of each object, i.e., segment objects may be - in different containers. | -All segment objects must be in the same - container | -
| Manifest Object Metadata | -The object has
- X-Static-Large-Object set to
- true. You do not set this
- metadata directly. Instead the system sets it
- when you &PUT; a static manifest object. |
- The X-Object-Manifest value is
- the <container>/<prefix>
- indicating where the segment objects are
- located. You supply this request header in the
- &PUT; operation |
-
| Making a copy of the manifest object | -To make a copy of the manifest object, include
- the ?multipart-manifest=get query
- string with the © operation. The new
- object contains the same manifest as the
- original. The segment objects are not copied.
- Instead, both the original and new manifest
- objects share the same set of segment
- objects. |
- The © operation does not create a
- manifest object. To duplicate a manifest
- object, use the &GET; operation to read the
- value of X-Object-Manifest and
- use this value in the
- X-Object-Manifest request
- header in a &PUT; operation. This creates a
- new manifest object that shares the same set
- of segment objects as the original manifest
- object. |
-
Content-Length or
- Content-Type header in the request.
- If the MD5 checksum of the data written to the storage
- system does NOT match the (optionally) supplied ETag
- value, a 422 (Unprocessable Entity) response is
- returned.ETag
- response header returned by the&PUT;
- operation. 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.?multipart-manifest=put query
- string at the end of the manifest object
- name.path - this is the container
- and object name in the following format:
- <container-name>/<object-name>etag - this is the MD5 checksum
- of the content of the segment object. This
- must match the ETag of that
- object.size_bytes - this is the size
- of the segment object. This must match the
- Content-Length of that
- objectContent-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 may also set the
- Content-Type request header and
- custom object metadata.?multipart-manifest=put query string,
- 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 &PUT;operation will
- fail.X-Static-Large-Object
- metadata is set to true indicating that
- this is a static object manifest.?multipart-manifest=get. The
- resulting list will not be identically formatted as
- the manifest you originally used in the &PUT;
- operation.?multipart-manifest=delete, the
- segment objects are deleted and if all are
- successfully deleted, the manifest object is also
- deleted.?multipart-manifest=put query string.
- This will create a | X-Container-Meta-Access-Control-Allow-Origin | -Origins to be allowed to make Cross Origin Requests, space separated. | -
| X-Container-Meta-Access-Control-Max-Age | -Max age for the Origin to hold the preflight results. | -
| X-Container-Meta-Access-Control-Expose-Headers | -Headers exposed to the user agent (e.g. browser) in the the actual request response. Space separated. | -
X-Delete-After or
- X-Delete-At header when doing a &PUT; or
- &POST; on the object, it is scheduled for deletion. This
- feature is helpful for objects you do not want to
- permanently store, such as log files, recurring full
- backups of a dataset, or documents or images you know will
- be outdated at a future time.X-Delete-At header requires a Unix
- Epoch timestamp, in integer form; for example: 1348691905
- represents Wed, 26 Sep 2012 20:38:25 GMT.
- By
- setting the header to a specific Epoch time, you indicate
- when you want the object to expire, not be served, and be
- deleted completely from the storage system.X-Delete-After header takes an integer
- number of seconds and calculates the amount of time from
- now that you want the object to be deleted. The proxy
- server that receives the request converts this header into
- an X-Delete-At header and calculates the
- deletion time using its current time plus the value given
- in seconds.X-Delete-At header
- is assigned with a Unix Epoch timestamp in integer
- form for Mon, 11 Jun 2012 15:38:25 GMT. Use http://www.epochconverter.com/ for example
- timestamps and a batch converter.X-Delete-After header
- is assigned a value in seconds, equivalent to 10 days.
- After this time, the object expires.allow_versions to TRUE in
- their container config. Then, create a container where
- your non-current versions will be written. Next, set the
- metadata X-Versions-Location header on the
- container that holds the current versions of your objects.
- Set the metadata header to point to the new non-current
- version container you created. The name of the container
- must be UTF-8 encoded and then URL-encoded before putting
- into the X-Versions-Location header. This is
- where your non-current versions will be stored. Once this
- is done, each object in your current-version container
- will have Object Versioning enabled; changes to the
- objects automatically create non-current versions in the
- separate container.X-Versions-Location
- metadata by sending an empty key value.X-Versions-Location header. In this
- example, this container is named "current". You can
- also add the X-Versions-Location header
- to an existing container. In this example, the name of
- the container is “versions”; the location for the
- current version is the container "current".X-Versions-Location header that
- references "versions".“X-Copy-From” header to designate the
- source of the data. The header value should be the
- container and object name of the source object in the form
- of “/container/object”. The container and object name must
- be UTF-8 encoded and then URL-encoded. Also, the
- X-Copy-From &PUT; requests require a
- Content-Length header, even if it is zero (0).X-Object-Manifest or
- X-Static-Large-Object:true metadata, the
- copy operation concatenates the segment objects when
- making the content for the destination object. You cannot
- copy an object larger than 5GB (by default). Refer to
- Large Object
- Creation for more information about large
- objects.?multipart-manifest=get query string to
- indicate that you want a copy of the manifest object. The
- new object will contain the same manifest as the original.
- The segment objects are not copied. Instead, both the
- original and new manifest objects share the same set of
- segment objects.?multipart-manifest=delete. The
- segment objects are deleted and if all are successfully
- deleted, the manifest object is also deleted.X-Delete-At or
- X-Delete-After header assigned are
- deleted within one day of the expiration time and the
- object is not served immediately after the expiration
- time. Refer to Expiring Objects for more details.X-Delete-At or
- X-Delete-After for expiring objects. You
- cannot use the &POST; operation to change any of the
- object's other headers such as Content-Type,
- ETag, etc. It is not used to upload
- storage objects (see &PUT;). Also refer to copying an object when
- you need to update metadata or other headers such as
- Content-Type or CORS headers.X-Object-Meta-. A &POST; request will
- delete all existing metadata added with a previous
- &PUT;/&POST;.X-NewestX-newest header to
- True in HEAD and GET requests to have
- Object Storage return the latest version of the account.
- If set to True, Object Storage queries all
- replicas to return the most recent one. Without this header,
- Object Storage responds faster after it finds one valid replica.
- Because setting this header to True is more
- expensive for the back end, use it only when it is
- absolutely needed.
- X-Storage-Url
- for an account are performed to list storage containers
- sorted by name. The sort order for the name is based on a
- binary comparison, a single built-in collating
- sequence that compares string data by using the SQLite
- memcmp() function, regardless of text encoding. The
- following list describes the optional query parameters
- that are supported with this request.limitmarkerend_markerformatjson or
- xml to return the respective
- serialized response.prefix query parameter is
- not supported at the account level.format=xml or
- format=json argument is appended to
- the storage account URL, the service serves extended
- container information serialized in the chosen format.
- The sample responses are formatted for readability.end_marker we can limit
- the result set to container names less than the
- given value.X-Account-Container-Count and
- X-Account-Bytes-Used. Since the storage
- system is designed to store large amounts of data, care
- should be taken when representing the total bytes response
- as an integer; when possible, convert it to a 64-bit
- unsigned integer if your platform supports that primitive
- type.X-Account-Meta-*.X-Account-Meta-Book header.X-Remove-Account-Meta-Book: x. The
- X-Versions-Location header. This
+ header enables object versioning for all objects in
+ the