NotImplemented

What Does Not Implemented Mean?

NotImplemented is a "Feature Gap" signal. Unlike 400 Malformed, S3 understands what you want but says "I have not built that yet." This is the primary error code returned by S3-compatible services (MinIO, Ceph) when you attempt advanced AWS operations like Object Lock, Intelligent Tiering, or specific checksum algorithms that their API layer does not support.

Common Causes

• -S3-Compatible Gaps: Using a self-hosted S3 service that lacks advanced features like Object Lock, Lifecycle policies, or Replication.
• -Unsupported Transfer Encodings: Sending Transfer-Encoding: gzip or other non-standard values that S3 recognizes as HTTP but does not implement for its storage logic.
• -SDK Version Mismatch: Upgrading to a modern SDK that sends new headers (e.g., x-amz-checksum-algorithm) to an older on-premises S3 gateway.
• -Regional Limitations: Attempting to use S3 Express One Zone or specific encryption headers in a region where they are not deployed yet.

How to Fix Not Implemented

1. 1Check the "Message" Field: S3 usually tells you exactly which header caused the issue (e.g., "A header you provided implies functionality that is not implemented").
2. 2Fallback to Core APIs: If on a compatible service, stick to core S3 operations (PUT, GET, DELETE, LIST) and avoid bucket-level management APIs.
3. 3Downgrade Checksum Logic: Disable newer SDK features like httpChecksumRequired if the target gateway does not support it.
4. 4Upgrade the Provider: If using MinIO or Ceph, ensure you are running the latest version to get the most complete S3 API coverage.

Step-by-Step Diagnosis for Not Implemented

1. 1Run the request with --debug to see exactly which x-amz- headers are being injected by the SDK.
2. 2Identify the endpoint: is this s3.amazonaws.com or a custom URL? Compatible services are the most common source.
3. 3Compare the operation against the provider compatibility matrix (for example MinIO S3 API support).
4. 4Check for Transfer-Encoding or Content-Encoding headers that might be confusing the storage gateway.

try {
  await s3.send(new PutObjectCommand({
    Bucket,
    Key,
    Body,
    ChecksumAlgorithm: "CRC32"
  }));
} catch (err) {
  if (err.name === 'NotImplemented') {
    console.warn("Checksum not supported by provider. Retrying without it...");
    // Fallback logic
  }
}

aws s3api put-object --bucket my-bucket --key test.txt --body . --debug
# Inspect the output for "x-amz-..." headers and 501 status

How to Verify the Fix

• -Successfully perform a basic PutObject without the offending header or feature flag.
• -Confirm the target S3-compatible service documentation marks the remaining operation as supported.
• -Verify that bypassing the advanced feature lets the broader application flow complete successfully.

How to Prevent Recurrence

• -Standardize on Core APIs: When building for hybrid clouds, design around the least common denominator of S3 features.
• -API Feature Probing: Implement a startup capability check that tries feature-specific operations and records unsupported ones.
• -SDK Configuration: Explicitly disable unsupported headers in SDK client options when targeting on-prem or compatible storage.
• -Pro-tip: If you must use Object Lock or lifecycle rules on-prem, prefer provider-specific guidance or libraries instead of assuming full AWS parity.

Related Errors

Decision Support

Official References

• -S3 Compatibility Matrix (Common Providers)
• -AWS S3 API Error Responses
• -AWS Official Documentation