Skip to main content
A newer release of this product is available.

GET container consistency request

Contributors netapp-perveilerk netapp-lhalbert
PDFs

Consistency controls provide a balance 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

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
Host: test.com

Response

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.

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
Related information

Use tenant account