public final class MultipartS3AsyncClient extends DelegatingS3AsyncClient
S3AsyncClient that automatically converts put, copy requests to their respective multipart call. Note: get is not
yet supported.MultipartConfigurationSERVICE_METADATA_ID, SERVICE_NAME| Modifier and Type | Method and Description |
|---|---|
void |
close() |
CompletableFuture<CopyObjectResponse> |
copyObject(CopyObjectRequest copyObjectRequest)
Creates a copy of an object that is already stored in Amazon S3.
|
static MultipartS3AsyncClient |
create(S3AsyncClient client,
MultipartConfiguration multipartConfiguration) |
<ReturnT> CompletableFuture<ReturnT> |
getObject(GetObjectRequest getObjectRequest,
AsyncResponseTransformer<GetObjectResponse,ReturnT> asyncResponseTransformer)
Retrieves objects from Amazon S3.
|
CompletableFuture<PutObjectResponse> |
putObject(PutObjectRequest putObjectRequest,
AsyncRequestBody requestBody)
Adds an object to a bucket.
|
abortMultipartUpload, completeMultipartUpload, createBucket, createMultipartUpload, delegate, deleteBucket, deleteBucketAnalyticsConfiguration, deleteBucketCors, deleteBucketEncryption, deleteBucketIntelligentTieringConfiguration, deleteBucketInventoryConfiguration, deleteBucketLifecycle, deleteBucketMetricsConfiguration, deleteBucketOwnershipControls, deleteBucketPolicy, deleteBucketReplication, deleteBucketTagging, deleteBucketWebsite, deleteObject, deleteObjects, deleteObjectTagging, deletePublicAccessBlock, getBucketAccelerateConfiguration, getBucketAcl, getBucketAnalyticsConfiguration, getBucketCors, getBucketEncryption, getBucketIntelligentTieringConfiguration, getBucketInventoryConfiguration, getBucketLifecycleConfiguration, getBucketLocation, getBucketLogging, getBucketMetricsConfiguration, getBucketNotificationConfiguration, getBucketOwnershipControls, getBucketPolicy, getBucketPolicyStatus, getBucketReplication, getBucketRequestPayment, getBucketTagging, getBucketVersioning, getBucketWebsite, getObjectAcl, getObjectAttributes, getObjectLegalHold, getObjectLockConfiguration, getObjectRetention, getObjectTagging, getObjectTorrent, getPublicAccessBlock, headBucket, headObject, invokeOperation, listBucketAnalyticsConfigurations, listBucketIntelligentTieringConfigurations, listBucketInventoryConfigurations, listBucketMetricsConfigurations, listBuckets, listMultipartUploads, listObjects, listObjectsV2, listObjectVersions, listParts, putBucketAccelerateConfiguration, putBucketAcl, putBucketAnalyticsConfiguration, putBucketCors, putBucketEncryption, putBucketIntelligentTieringConfiguration, putBucketInventoryConfiguration, putBucketLifecycleConfiguration, putBucketLogging, putBucketMetricsConfiguration, putBucketNotificationConfiguration, putBucketOwnershipControls, putBucketPolicy, putBucketReplication, putBucketRequestPayment, putBucketTagging, putBucketVersioning, putBucketWebsite, putObjectAcl, putObjectLegalHold, putObjectLockConfiguration, putObjectRetention, putObjectTagging, putPublicAccessBlock, restoreObject, selectObjectContent, serviceClientConfiguration, serviceName, uploadPart, uploadPartCopy, utilities, waiter, writeGetObjectResponseclone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, waitabortMultipartUpload, builder, completeMultipartUpload, copyObject, create, createBucket, createMultipartUpload, crtBuilder, crtCreate, deleteBucket, deleteBucketAnalyticsConfiguration, deleteBucketCors, deleteBucketEncryption, deleteBucketIntelligentTieringConfiguration, deleteBucketInventoryConfiguration, deleteBucketLifecycle, deleteBucketMetricsConfiguration, deleteBucketOwnershipControls, deleteBucketPolicy, deleteBucketReplication, deleteBucketTagging, deleteBucketWebsite, deleteObject, deleteObjects, deleteObjectTagging, deletePublicAccessBlock, getBucketAccelerateConfiguration, getBucketAcl, getBucketAnalyticsConfiguration, getBucketCors, getBucketEncryption, getBucketIntelligentTieringConfiguration, getBucketInventoryConfiguration, getBucketLifecycleConfiguration, getBucketLocation, getBucketLogging, getBucketMetricsConfiguration, getBucketNotificationConfiguration, getBucketOwnershipControls, getBucketPolicy, getBucketPolicyStatus, getBucketReplication, getBucketRequestPayment, getBucketTagging, getBucketVersioning, getBucketWebsite, getObject, getObject, getObject, getObjectAcl, getObjectAttributes, getObjectLegalHold, getObjectLockConfiguration, getObjectRetention, getObjectTagging, getObjectTorrent, getObjectTorrent, getObjectTorrent, getPublicAccessBlock, headBucket, headObject, listBucketAnalyticsConfigurations, listBucketIntelligentTieringConfigurations, listBucketInventoryConfigurations, listBucketMetricsConfigurations, listBuckets, listBuckets, listMultipartUploads, listMultipartUploadsPaginator, listMultipartUploadsPaginator, listObjects, listObjectsV2, listObjectsV2Paginator, listObjectsV2Paginator, listObjectVersions, listObjectVersionsPaginator, listObjectVersionsPaginator, listParts, listPartsPaginator, listPartsPaginator, putBucketAccelerateConfiguration, putBucketAcl, putBucketAnalyticsConfiguration, putBucketCors, putBucketEncryption, putBucketIntelligentTieringConfiguration, putBucketInventoryConfiguration, putBucketLifecycleConfiguration, putBucketLogging, putBucketMetricsConfiguration, putBucketNotificationConfiguration, putBucketOwnershipControls, putBucketPolicy, putBucketReplication, putBucketRequestPayment, putBucketTagging, putBucketVersioning, putBucketWebsite, putObject, putObject, putObject, putObjectAcl, putObjectLegalHold, putObjectLockConfiguration, putObjectRetention, putObjectTagging, putPublicAccessBlock, restoreObject, selectObjectContent, uploadPart, uploadPart, uploadPart, uploadPartCopy, writeGetObjectResponse, writeGetObjectResponse, writeGetObjectResponsepublic CompletableFuture<PutObjectResponse> putObject(PutObjectRequest putObjectRequest, AsyncRequestBody requestBody)
DelegatingS3AsyncClientAdds an object to a bucket. You must have WRITE permissions on a bucket to add an object to it.
Amazon S3 never adds partial objects; if you receive a success response, Amazon S3 added the entire object to the
bucket. You cannot use PutObject to only update a single piece of metadata for an existing object.
You must put the entire object with updated metadata if you want to update some values.
Amazon S3 is a distributed system. If it receives multiple write requests for the same object simultaneously, it overwrites all but the last object written. To prevent objects from being deleted or overwritten, you can use Amazon S3 Object Lock.
To ensure that data is not corrupted traversing the network, use the Content-MD5 header. When you
use this header, Amazon S3 checks the object against the provided MD5 value and, if they do not match, returns an
error. Additionally, you can calculate the MD5 while putting an object to Amazon S3 and compare the returned ETag
to the calculated MD5 value.
To successfully complete the PutObject request, you must have the s3:PutObject in your
IAM permissions.
To successfully change the objects acl of your PutObject request, you must have the
s3:PutObjectAcl in your IAM permissions.
To successfully set the tag-set with your PutObject request, you must have the
s3:PutObjectTagging in your IAM permissions.
The Content-MD5 header is required for any request to upload an object with a retention period
configured using Amazon S3 Object Lock. For more information about Amazon S3 Object Lock, see Amazon S3 Object Lock
Overview in the Amazon S3 User Guide.
You have four mutually exclusive options to protect data using server-side encryption in Amazon S3, depending on how you choose to manage the encryption keys. Specifically, the encryption key options are Amazon S3 managed keys (SSE-S3), Amazon Web Services KMS keys (SSE-KMS or DSSE-KMS), and customer-provided keys (SSE-C). Amazon S3 encrypts data with server-side encryption by using Amazon S3 managed keys (SSE-S3) by default. You can optionally tell Amazon S3 to encrypt data at rest by using server-side encryption with other key options. For more information, see Using Server-Side Encryption.
When adding a new object, you can use headers to grant ACL-based permissions to individual Amazon Web Services accounts or to predefined groups defined by Amazon S3. These permissions are then added to the ACL on the object. By default, all objects are private. Only the owner has full access control. For more information, see Access Control List (ACL) Overview and Managing ACLs Using the REST API.
If the bucket that you're uploading objects to uses the bucket owner enforced setting for S3 Object Ownership,
ACLs are disabled and no longer affect permissions. Buckets that use this setting only accept PUT requests that
don't specify an ACL or PUT requests that specify bucket owner full control ACLs, such as the
bucket-owner-full-control canned ACL or an equivalent form of this ACL expressed in the XML format.
PUT requests that contain other ACLs (for example, custom grants to certain Amazon Web Services accounts) fail
and return a 400 error with the error code AccessControlListNotSupported. For more
information, see
Controlling ownership of objects and disabling ACLs in the Amazon S3 User Guide.
If your bucket uses the bucket owner enforced setting for Object Ownership, all objects written to the bucket by any account will be owned by the bucket owner.
By default, Amazon S3 uses the STANDARD Storage Class to store newly created objects. The STANDARD storage class provides high durability and high availability. Depending on performance needs, you can specify a different Storage Class. Amazon S3 on Outposts only uses the OUTPOSTS Storage Class. For more information, see Storage Classes in the Amazon S3 User Guide.
If you enable versioning for a bucket, Amazon S3 automatically generates a unique version ID for the object being stored. Amazon S3 returns this ID in the response. When you enable versioning for a bucket, if Amazon S3 receives multiple write requests for the same object simultaneously, it stores all of the objects. For more information about versioning, see Adding Objects to Versioning-Enabled Buckets. For information about returning the versioning state of a bucket, see GetBucketVersioning.
For more information about related Amazon S3 APIs, see the following:
putObject in interface S3AsyncClientputObject in class DelegatingS3AsyncClientrequestBody - Functional interface that can be implemented to produce the request content in a non-blocking manner. The
size of the content is expected to be known up front. See AsyncRequestBody for specific details on
implementing this interface as well as links to precanned implementations for common scenarios like
uploading from a file. The service documentation for the request content is as follows '
Object data.
'public CompletableFuture<CopyObjectResponse> copyObject(CopyObjectRequest copyObjectRequest)
DelegatingS3AsyncClientCreates a copy of an object that is already stored in Amazon S3.
You can store individual objects of up to 5 TB in Amazon S3. You create a copy of your object up to 5 GB in size in a single atomic action using this API. However, to copy an object greater than 5 GB, you must use the multipart upload Upload Part - Copy (UploadPartCopy) API. For more information, see Copy Object Using the REST Multipart Upload API.
All copy requests must be authenticated. Additionally, you must have read access to the source object and write access to the destination bucket. For more information, see REST Authentication. Both the Region that you want to copy the object from and the Region that you want to copy the object to must be enabled for your account.
A copy request might return an error when Amazon S3 receives the copy request or while Amazon S3 is copying the
files. If the error occurs before the copy action starts, you receive a standard Amazon S3 error. If the error
occurs during the copy operation, the error response is embedded in the 200 OK response. This means
that a 200 OK response can contain either a success or an error. If you call the S3 API directly,
make sure to design your application to parse the contents of the response and handle it appropriately. If you
use Amazon Web Services SDKs, SDKs handle this condition. The SDKs detect the embedded error and apply error
handling per your configuration settings (including automatically retrying the request as appropriate). If the
condition persists, the SDKs throws an exception (or, for the SDKs that don't use exceptions, they return the
error).
If the copy is successful, you receive a response with information about the copied object.
If the request is an HTTP 1.1 request, the response is chunk encoded. If it were not, it would not contain the content-length, and you would need to read the entire body.
The copy request charge is based on the storage class and Region that you specify for the destination object. The request can also result in a data retrieval charge for the source if the source storage class bills for data retrieval. For pricing information, see Amazon S3 pricing.
Amazon S3 transfer acceleration does not support cross-Region copies. If you request a cross-Region copy using a
transfer acceleration endpoint, you get a 400 Bad Request error. For more information, see Transfer Acceleration.
When copying an object, you can preserve all metadata (the default) or specify new metadata. However, the access control list (ACL) is not preserved and is set to private for the user making the request. To override the default ACL setting, specify a new ACL when generating a copy request. For more information, see Using ACLs.
To specify whether you want the object metadata copied from the source object or replaced with metadata provided
in the request, you can optionally add the x-amz-metadata-directive header. When you grant
permissions, you can use the s3:x-amz-metadata-directive condition key to enforce certain metadata
behavior when objects are uploaded. For more information, see Specifying Conditions in a
Policy in the Amazon S3 User Guide. For a complete list of Amazon S3-specific condition keys, see Actions, Resources, and Condition Keys
for Amazon S3.
x-amz-website-redirect-location is unique to each object and must be specified in the request
headers to copy the value.
To only copy an object under certain conditions, such as whether the Etag matches or whether the
object was modified before or after a specified date, use the following request parameters:
x-amz-copy-source-if-match
x-amz-copy-source-if-none-match
x-amz-copy-source-if-unmodified-since
x-amz-copy-source-if-modified-since
If both the x-amz-copy-source-if-match and x-amz-copy-source-if-unmodified-since
headers are present in the request and evaluate as follows, Amazon S3 returns 200 OK and copies the
data:
x-amz-copy-source-if-match condition evaluates to true
x-amz-copy-source-if-unmodified-since condition evaluates to false
If both the x-amz-copy-source-if-none-match and x-amz-copy-source-if-modified-since
headers are present in the request and evaluate as follows, Amazon S3 returns the
412 Precondition Failed response code:
x-amz-copy-source-if-none-match condition evaluates to false
x-amz-copy-source-if-modified-since condition evaluates to true
All headers with the x-amz- prefix, including x-amz-copy-source, must be signed.
Amazon S3 automatically encrypts all new objects that are copied to an S3 bucket. When copying an object, if you don't specify encryption information in your copy request, the encryption setting of the target object is set to the default encryption configuration of the destination bucket. By default, all buckets have a base level of encryption configuration that uses server-side encryption with Amazon S3 managed keys (SSE-S3). If the destination bucket has a default encryption configuration that uses server-side encryption with Key Management Service (KMS) keys (SSE-KMS), dual-layer server-side encryption with Amazon Web Services KMS keys (DSSE-KMS), or server-side encryption with customer-provided encryption keys (SSE-C), Amazon S3 uses the corresponding KMS key, or a customer-provided key to encrypt the target object copy.
When you perform a CopyObject operation, if you want to use a different type of encryption setting
for the target object, you can use other appropriate encryption-related headers to encrypt the target object with
a KMS key, an Amazon S3 managed key, or a customer-provided key. With server-side encryption, Amazon S3 encrypts
your data as it writes your data to disks in its data centers and decrypts the data when you access it. If the
encryption setting in your request is different from the default encryption configuration of the destination
bucket, the encryption setting in your request takes precedence. If the source object for the copy is stored in
Amazon S3 using SSE-C, you must provide the necessary encryption information in your request so that Amazon S3
can decrypt the object for copying. For more information about server-side encryption, see Using Server-Side
Encryption.
If a target object uses SSE-KMS, you can enable an S3 Bucket Key for the object. For more information, see Amazon S3 Bucket Keys in the Amazon S3 User Guide.
When copying an object, you can optionally use headers to grant ACL-based permissions. By default, all objects are private. Only the owner has full access control. When adding a new object, you can grant permissions to individual Amazon Web Services accounts or to predefined groups that are defined by Amazon S3. These permissions are then added to the ACL on the object. For more information, see Access Control List (ACL) Overview and Managing ACLs Using the REST API.
If the bucket that you're copying objects to uses the bucket owner enforced setting for S3 Object Ownership, ACLs
are disabled and no longer affect permissions. Buckets that use this setting only accept PUT
requests that don't specify an ACL or PUT requests that specify bucket owner full control ACLs, such
as the bucket-owner-full-control canned ACL or an equivalent form of this ACL expressed in the XML
format.
For more information, see Controlling ownership of objects and disabling ACLs in the Amazon S3 User Guide.
If your bucket uses the bucket owner enforced setting for Object Ownership, all objects written to the bucket by any account will be owned by the bucket owner.
When copying an object, if it has a checksum, that checksum will be copied to the new object by default. When you
copy the object over, you can optionally specify a different checksum algorithm to use with the
x-amz-checksum-algorithm header.
You can use the CopyObject action to change the storage class of an object that is already stored in
Amazon S3 by using the StorageClass parameter. For more information, see Storage Classes in the
Amazon S3 User Guide.
If the source object's storage class is GLACIER or DEEP_ARCHIVE, or the object's storage class is INTELLIGENT_TIERING and it's S3 Intelligent-Tiering access tier is Archive Access or Deep Archive Access, you must restore a copy of this object before you can use it as a source object for the copy operation. For more information, see RestoreObject. For more information, see Copying Objects.
By default, x-amz-copy-source header identifies the current version of an object to copy. If the
current version is a delete marker, Amazon S3 behaves as if the object was deleted. To copy a different version,
use the versionId subresource.
If you enable versioning on the target bucket, Amazon S3 generates a unique version ID for the object being
copied. This version ID is different from the version ID of the source object. Amazon S3 returns the version ID
of the copied object in the x-amz-version-id response header in the response.
If you do not enable versioning or suspend it on the target bucket, the version ID that Amazon S3 generates is always null.
The following operations are related to CopyObject:
copyObject in interface S3AsyncClientcopyObject in class DelegatingS3AsyncClientpublic <ReturnT> CompletableFuture<ReturnT> getObject(GetObjectRequest getObjectRequest, AsyncResponseTransformer<GetObjectResponse,ReturnT> asyncResponseTransformer)
DelegatingS3AsyncClient
Retrieves objects from Amazon S3. To use GET, you must have READ access to the object.
If you grant READ access to the anonymous user, you can return the object without using an
authorization header.
An Amazon S3 bucket has no directory hierarchy such as you would find in a typical computer file system. You can,
however, create a logical hierarchy by using object key names that imply a folder structure. For example, instead
of naming an object sample.jpg, you can name it photos/2006/February/sample.jpg.
To get an object from such a logical hierarchy, specify the full key name for the object in the GET
operation. For a virtual hosted-style request example, if you have the object
photos/2006/February/sample.jpg, specify the resource as
/photos/2006/February/sample.jpg. For a path-style request example, if you have the object
photos/2006/February/sample.jpg in the bucket named examplebucket, specify the resource
as /examplebucket/photos/2006/February/sample.jpg. For more information about request types, see HTTP Host
Header Bucket Specification.
For more information about returning the ACL of an object, see GetObjectAcl.
If the object you are retrieving is stored in the S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive
storage class, or S3 Intelligent-Tiering Archive or S3 Intelligent-Tiering Deep Archive tiers, before you can
retrieve the object you must first restore a copy using RestoreObject. Otherwise, this
action returns an InvalidObjectState error. For information about restoring archived objects, see Restoring Archived Objects.
Encryption request headers, like x-amz-server-side-encryption, should not be sent for GET requests
if your object uses server-side encryption with Key Management Service (KMS) keys (SSE-KMS), dual-layer
server-side encryption with Amazon Web Services KMS keys (DSSE-KMS), or server-side encryption with Amazon S3
managed encryption keys (SSE-S3). If your object does use these types of keys, you’ll get an HTTP 400 Bad Request
error.
If you encrypt an object by using server-side encryption with customer-provided encryption keys (SSE-C) when you store the object in Amazon S3, then when you GET the object, you must use the following headers:
x-amz-server-side-encryption-customer-algorithm
x-amz-server-side-encryption-customer-key
x-amz-server-side-encryption-customer-key-MD5
For more information about SSE-C, see Server-Side Encryption (Using Customer-Provided Encryption Keys).
Assuming you have the relevant permission to read object tags, the response also returns the
x-amz-tagging-count header that provides the count of number of tags associated with the object. You
can use GetObjectTagging
to retrieve the tag set associated with an object.
You need the relevant read object (or version) permission for this operation. For more information, see Specifying Permissions in a
Policy. If the object that you request doesn’t exist, the error that Amazon S3 returns depends on whether you
also have the s3:ListBucket permission.
If you have the s3:ListBucket permission on the bucket, Amazon S3 returns an HTTP status code 404
(Not Found) error.
If you don’t have the s3:ListBucket permission, Amazon S3 returns an HTTP status code 403
("access denied") error.
By default, the GET action returns the current version of an object. To return a different version,
use the versionId subresource.
If you supply a versionId, you need the s3:GetObjectVersion permission to access a
specific version of an object. If you request a specific version, you do not need to have the
s3:GetObject permission. If you request the current version without a specific version ID, only
s3:GetObject permission is required. s3:GetObjectVersion permission won't be required.
If the current version of the object is a delete marker, Amazon S3 behaves as if the object was deleted and
includes x-amz-delete-marker: true in the response.
For more information about versioning, see PutBucketVersioning.
There are times when you want to override certain response header values in a GET response. For
example, you might override the Content-Disposition response header value in your GET
request.
You can override values for a set of response headers using the following query parameters. These response header
values are sent only on a successful request, that is, when status code 200 OK is returned. The set of headers
you can override using these parameters is a subset of the headers that Amazon S3 accepts when you create an
object. The response headers that you can override for the GET response are
Content-Type, Content-Language, Expires, Cache-Control,
Content-Disposition, and Content-Encoding. To override these header values in the
GET response, you use the following request parameters.
You must sign the request, either using an Authorization header or a presigned URL, when using these parameters. They cannot be used with an unsigned (anonymous) request.
response-content-type
response-content-language
response-expires
response-cache-control
response-content-disposition
response-content-encoding
If both of the If-Match and If-Unmodified-Since headers are present in the request as
follows: If-Match condition evaluates to true, and; If-Unmodified-Since
condition evaluates to false; then, S3 returns 200 OK and the data requested.
If both of the If-None-Match and If-Modified-Since headers are present in the request
as follows: If-None-Match condition evaluates to false, and;
If-Modified-Since condition evaluates to true; then, S3 returns 304 Not Modified
response code.
For more information about conditional requests, see RFC 7232.
The following operations are related to GetObject:
getObject in interface S3AsyncClientgetObject in class DelegatingS3AsyncClientasyncResponseTransformer - The response transformer for processing the streaming response in a non-blocking manner. See
AsyncResponseTransformer for details on how this callback should be implemented and for links to
precanned implementations for common scenarios like downloading to a file. The service documentation for
the response content is as follows '
Object data.
'.public void close()
close in interface AutoCloseableclose in interface SdkAutoCloseableclose in class DelegatingS3AsyncClientpublic static MultipartS3AsyncClient create(S3AsyncClient client, MultipartConfiguration multipartConfiguration)
Copyright © 2023. All rights reserved.