S3 API Compatibility
This page documents S3 APIs supported by MinIO AIStor. For reference documentation on any given API, see the corresponding documentation for Amazon S3.
Object APIs
Conditional headers
MinIO AIStor supports conditional operations using the following HTTP headers:
| Header | Supported operations |
|---|---|
If-Match |
GetObject, HeadObject, PutObject, CopyObject, DeleteObject, CreateMultipartUpload |
If-None-Match |
GetObject, HeadObject, PutObject, CopyObject, CreateMultipartUpload |
If-Modified-Since |
GetObject, HeadObject |
If-Unmodified-Since |
GetObject, HeadObject |
x-amz-copy-source-if-match |
CopyObject, UploadPartCopy |
x-amz-copy-source-if-none-match |
CopyObject, UploadPartCopy |
x-amz-copy-source-if-modified-since |
CopyObject, UploadPartCopy |
x-amz-copy-source-if-unmodified-since |
CopyObject, UploadPartCopy |
DeleteObjects supports conditional deletes using the <ETag> element in the request body.
Object locking
Unsupported object APIs
- GetObjectAcl
- PutObjectAcl
Multipart uploads
Differences from S3 APIs for multipart uploads
-
ListMultipartUploadsrequires the exact object name as a prefix. -
The
AbortIncompleteMultipartUploadlifecycle action is not supported withPutBucketLifecycle.
Bucket APIs
Bucket replication
Bucket lifecycle
Bucket notifications
Bucket policies
Unsupported bucket API operations
- GetBucketInventoryConfiguration
- PutBucketInventoryConfiguration
- DeleteBucketInventoryConfiguration
- GetBucketMetricsConfiguration
- PutBucketMetricsConfiguration
- DeleteBucketMetricsConfiguration
- PutBucketWebsite
- GetBucketLogging
- PutBucketLogging
- PutBucketAccelerateConfiguration
- DeleteBucketAccelerateConfiguration
- PutBucketRequestPayment
- DeleteBucketRequestPayment
- PutBucketAcl
- HeadBucketAcl
- GetPublicAccessBlock
- PutPublicAccessBlock
- DeletePublicAccessBlock
- GetBucketOwnershipControls
- PutBucketOwnershipControls
- DeleteBucketOwnershipControls
- GetBucketIntelligentTieringConfiguration
- PutBucketIntelligentTieringConfiguration
- ListBucketIntelligentTieringConfigurations
- DeleteBucketIntelligentTieringConfiguration
- GetBucketAnalyticsConfiguration
MinIO AIStor alternatives for unsupported bucket API operations
- For calls to
BucketACLorObjectACLoperations, use Policies. - For calls to
BucketWebsiteoperations, usecaddyornginx. - For calls to
BucketAnalytics,BucketMetrics, orBucketLoggingoperations, use Bucket notifications.
S3 extensions
MinIO AIStor extends the S3 API with additional capabilities, including Object Lambda for on-the-fly object transformation during retrieval and the S3 ZIP Extension for reading individual files inside ZIP archives without extracting them first.
S3 over RDMA
On a deployment running the RDMA build, GetObject, PutObject, and UploadPart can transfer object data directly between client memory and the server over RDMA, using the AWS S3 RDMA protocol.
GetObject writes into the client’s buffer; PutObject and UploadPart read from it.
That buffer is usually GPU memory, which is where RDMA pays off most, but host memory works too and needs no GPU.
The client opts in per request with a header; there is no server setting.
| Header | Direction | Description |
|---|---|---|
x-amz-rdma-token |
Request | The client’s RDMA buffer descriptor. |
x-amz-rdma-reply |
Response | 200 or 206 when the transfer used RDMA, 501 when the server declined. |
x-amz-rdma-bytes-transferred |
Response | Bytes transferred out of band, when non-zero. |
On a successful RDMA transfer the server sets Content-Length: 0, because the object bytes did not travel in the HTTP response.
When the server declines, it returns an S3 error response rather than serving the object over HTTP.
Retrying without the x-amz-rdma-token header is the client’s responsibility.
The MinIO SDKs below handle this automatically.
Reliable Connection clients first perform a handshake at POST /rdma/connect, exchanging descriptors through the same x-amz-rdma-token header. Dynamically Connected clients do not use this route.
SDK support
S3 over RDMA is supported by the MinIO SDKs for Go, C++, Rust, and Python.
Each of them uses NVIDIA cuObjClient to move the object payload between GPU memory and the network adapter.
For worked examples in each language, see Transfer Objects over RDMA.
For deployment, see RDMA acceleration.
S3 Express mode
When MinIO AIStor runs in S3 Express mode, the supported S3 API surface differs from the default S3 API mode.
S3 Express mode also adds the AppendObject behavior, which lets a client append data to an existing object by issuing a PutObject request with the x-amz-write-offset-bytes header.
For the list of operations supported and disabled in S3 Express mode, see S3 Express mode.
MinIO-specific error codes
In addition to the standard S3 error codes, MinIO AIStor returns the following MinIO-specific error codes:
| Code | HTTP status | Description |
|---|---|---|
NotSupported |
501 | API operation not implemented. |
NotImplemented |
501 | KMS not configured or feature unavailable. |
XMinioHealNotImplemented |
400 | Healing not available in this mode. |
XMinioLDAPNotEnabled |
501 | LDAP must be enabled for this operation. |
InvalidToken |
400 | Object Lambda output token mismatch. |
LambdaFunctionStatusError |
400 | Object Lambda function returned an invalid status. |
RDMATransferError |
503 | An S3-over-RDMA transfer failed. Retry the request, without the x-amz-rdma-token header to fall back to HTTP. |
KMS error codes
KMS-backed operations return these codes, including when the KMS itself is unreachable:
| Code | HTTP status | Description |
|---|---|---|
kms:NotAuthorized |
403 | The KMS credentials lack permission for the operation. |
kms:KeyNotFound |
404 | No key exists with the given key ID. |
kms:KeyAlreadyExists |
409 | A key already exists with the given key ID. |
kms:InvalidCiphertextException |
400 | The ciphertext could not be decrypted. The key material does not match. |
kms:DecryptionFailed |
503 | The decryption request could not be completed at all, for example because the KMS was unreachable. Unlike kms:InvalidCiphertextException, this does not imply invalid ciphertext. Retry the request. |
kms:NotSupported |
501 | The configured KMS does not support the requested functionality. |
kms:KeyCreationFailed |
503 | The KMS could not create the key. |
kms:KeyDeletionFailed |
503 | The KMS could not delete the key. |
kms:KeyListingFailed |
503 | The KMS could not list keys. |
kms:KeyGenerationFailed |
503 | The KMS could not generate a data key. |
A request that the client cancels while a KMS operation is in flight returns status 499 rather than a KMS error.
A KMS-backed request previously returned 500 whatever the cause.
It now returns 503 when the KMS is unreachable, which distinguishes a retryable outage from an invalid ciphertext, and 499 when the client cancels the request.
Update any client retry logic or alerting rule that keys on a 500 response to a KMS-backed operation.