Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S3 Encryption client does throw an error for ranges greater than EOF #200

Open
ahmarsuhail opened this issue Mar 7, 2024 · 2 comments
Open

Comments

@ahmarsuhail
Copy link
Collaborator

Problem:

I created a 64KB (65536 bytes) with S3Encryption client, and then did

    S3Client s3Client = S3Client.builder().region(Region.EU_WEST_1).build();

    S3Client s3ECClient = S3EncryptionClient.builder()
             .kmsKeyId("xxx")
            .wrappedClient(s3Client)
            .wrappedAsyncClient(S3AsyncClient.builder().region(Region.EU_WEST_1).build())
           .enableLegacyUnauthenticatedModes(true)
           .build();



    ResponseInputStream<GetObjectResponse> inputStream = s3ECClient.getObject(GetObjectRequest.builder()
        .bucket("xxxx")
        .key("xxxx")
        .range("bytes=65536-65635").build());

So end of range 65635 is greater than EOF at 65536. And no error was thrown.

Creating a file with a regular S3 client and then doing

    ResponseInputStream<GetObjectResponse> inputStream = s3Client.getObject(GetObjectRequest.builder()
        .bucket("xxx")
        .key("xxxx")
        .range("bytes=65536-65635").build());

throws software.amazon.awssdk.services.s3.model.S3Exception: The requested range is not satisfiable (Service: S3, Status Code: 416, Request ID: which is what we expect to be thrown in S3A.

Solution:

S3 Encryption client should also throw a 416 range not satisfiable error.

@kessplas
Copy link
Contributor

Hello Ahmar,

I was able to reproduce this. The issue here is that when we implemented ranged gets in S3EC v3, we decided to maintain compatibility with the S3EC v1/v2 clients. In v1/v2 this form of range returns an empty object. Since this is a deliberate design decision, it would be a breaking change to modify the behavior at this point. Do you need SDK v2-style ranged get behavior specifically? If so, we would need to add it as a new feature i.e. with a configuration option to enable the behavior. Thanks!

@shameersss1
Copy link

@justplaz - Yes it would be great to add that to make sure downstream application doesn't break when using normal S3 client and encrypted S3 client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants