GET Bucket consistency request

The GET Bucket consistency request allows you to determine the consistency level being applied to a particular bucket.

The default consistency controls are set to guarantee read-after-write for newly created objects. For more information on the Consistency-Control header, see information about how StorageGRID Webscale implements the S3 REST API.

You must have the s3:GetBucketConsistency permission to complete this operation.

Request

Request HTTP Header	Description
Authorization	Specifies the AWS signature and the access key ID for the account to use for the request.
Date	The date and time of the request.
Host	The host name to which the request is directed.

Request example

GET /bucket?x-ntap-sg-consistency HTTP/1.1
Date: Sat, 29 Nov 2015 01:02:17 GMT
Authorization: AWS 9MOYPG9ACWPAJA1S72R5:jUGbYkLdBApjCWBgK4TxvOjfock=
Host: test.com

Response

Response HTTP Header	Description
Connection	Specifies whether the connection to the server is open or closed.
Content-Length	The length of the response body.
Content-Type	The Multipurpose Internet Mail Extensions (MIME) type of the response body.
Date	The date and time of the response.
Server	The server that created the response.
x-amz-request-id	The identifier that uniquely identifies the request. Created by the S3 API.

In the response XML, <Consistency> will return one of the following values:

all: Provides the highest guarantee of read-after-write consistency. 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.
default (read-after-write for new): Provides read-after-write consistency for new objects and eventual consistency for object updates. Offers high availability, and data protection guarantees. Matches AWS S3 consistency guarantees.
Note: If your application attempts HEAD operations on keys that do not exist, set the consistency level to available, unless you require AWS S3 consistency guarantees. Otherwise, a high number of 500 Internal Server errors can result if one or more Storage Nodes are unavailable.
available (eventual consistency for HEAD operations): Behaves the same as the default consistency level, but only provides eventual consistency for HEAD operations. Offers higher availability for HEAD operations than default if Storage Nodes are unavailable. Differs from AWS S3 consistency guarantees for HEAD operations only.
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 200 OK
Date: Sat, 29 Nov 2015 01:02:18 GMT
Connection: CLOSE
Server: StorageGRID/10.3.0
x-amz-request-id: 12345
Content-Length: 127
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<Consistency xmlns="http://s3.storagegrid.com/doc/2015-02-01/">default</Consistency>