GET container consistency request

Consistency level makes a trade-off between the availability of the objects and the consistency of those objects across different Storage Nodes and sites. The GET container consistency request allows you to determine the consistency level being applied to a particular container.


Request HTTP Header Description
X-Auth-Token Specifies the Swift authentication token for the account to use for the request.
x-ntap-sg-consistency Specifies the type of request, where true = GET container consistency, and false = GET container.
Host The hostname to which the request is directed.

Request example

GET /v1/28544923908243208806/Swift container
X-Auth-Token: SGRD_3a877009a2d24cb1801587bfa9050f29
x-ntap-sg-consistency: true


Response HTTP Header Description
Date The date and time of the response.
Connection Whether the connection to the server is open or closed.
X-Trans-Id The unique transaction identifier for the request.
Content-Length The length of the response body.
x-ntap-sg-consistency The consistency control level being applied to the container. The following values are supported:
  • all: All nodes receive the data immediately or the request will fail.
  • strong-global: Guarantees read-after-write consistency for all client requests across all sites.
  • strong-site: Guarantees read-after-write consistency for all client requests within a site.
  • read-after-new-write: Provides read-after-write consistency for new objects and eventual consistency for object updates. Offers high availability and data protection guarantees.
    Note: If your application uses HEAD requests on objects that do not exist, you might receive a high number of 500 Internal Server errors if one or more Storage Nodes are unavailable. To prevent these errors, use the "available" level.
  • available (eventual consistency for HEAD operations): Behaves the same as the "read-after-new-write" consistency level, but only provides eventual consistency for HEAD operations. Offers higher availability for HEAD operations than "read-after-new-write" if Storage Nodes are unavailable.
  • weak: Provides eventual consistency and high availability, with minimal data protection guarantees, especially if a Storage Node fails or is unavailable. Suitable only for write-heavy workloads that require high availability, do not require read-after-write consistency, and can tolerate the potential loss of data if a node fails.

Response example

HTTP/1.1 204 No Content
Date: Sat, 29 Nov 2015 01:02:18 GMT
Connection: CLOSE
X-Trans-Id: 1936575373
Content-Length: 0
x-ntap-sg-consistency: strong-site