You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[S3] Add support for more user-friendly CopyObject source parameters
## Motivation and Context
The current S3Client interface has a cumbersome API for invoking
CopyObjectRequests. We require users to define the bucket name, key
name, and version ID in a raw string format. We require that the string
conform to the S3 API, which forces users to know the intricate details
for how to join these values together. Additionally, portions (but not
all) of the value must be URL encoded, further increasing the burden.
https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObject.html#API_CopyObject_RequestParameters
In the Java SDK v1, users are given explicit parameters for the
different copy source attributes. But in v2, parity for this support is
clearly lacking. E.g.,
v1:
```
s3.copyObject(new CopyObjectRequest()
.withSourceBucketName(SOURCE_BUCKET)
.withSourceKey(key)
.withSourceVersionId(versionId)
.withDestinationBucketName(DESTINATION_BUCKET)
.withDestinationKey(key));
```
v2:
```
s3.copyObject(CopyObjectRequest.builder()
.copySource(SOURCE_BUCKET + "/" + key + "?versionId=" + versionId)
.destinationBucket(DESTINATION_BUCKET)
.destinationKey(key)
.build());
```
The v1 SDK will also URL encode on the user's behalf, allowing users to
use the same input values as they would for a PutObjectRequest. The v2
code snippet above may appear to work for most users until they run into
unexpected source keys that require URL encoding, at which point they
will typically be given `NoSuchKey` errors.
This API deficiency has been called out by users in at least the
following issues:
* aws#1313
* aws#1452
* aws#1656
* awsdocs/aws-doc-sdk-examples#740
## Description
* For both CopyObjectRequest and UploadPartCopyRequest, add explicit
parameters for: SourceBucket, SourceKey, SourceVersionId
* If specified, these values will be used to construct a CopySource on
the user's behalf, including URL encoding the relevant portions.
* These values are introduced in a backwards compatible fashion. Users
who are already using CopySource today will see no change in behavior,
but these new fields may not be used in conjunction with CopySource.
* A follow-up PR will be submitted to propose deprecating the current
CopySource parameter. It is excluded from this PR since our current code
gen configuration lacks appropriate support.
* Add support for "DestinationBucket" & "DestinationKey" to
UploadPartCopyRequest (this support already existed for
CopyObjectRequest)
* Utility function added to detect if an ARN is for a particular S3
resource type. This is to conform with the S3 API requirements of
inserting "/object" in the path of these requests.
## Testing
* New unit tests added
* New integration tests added
0 commit comments