-
Notifications
You must be signed in to change notification settings - Fork 13
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
Inconsistency behavior of the EncryptionClient wrt the regular client about end of stream behavior #300
Comments
@NathanEckert I ran your code; I cannot get your results. I had a hard time aligning your issue description with your code comments. I cannot detect any difference in behavior between This repo is for S3 Encryption Client for Java V3 (S3EC-Java-3.x), The objective of the S3EC-Java-3.x is to have API compatibility with the From what you have described, Is this correct? Is this newer vs older client behavior the root cause of this issue? If not, can you tell us exactly what version of the AWS SDK for Java you are using, Much Obliged, (Pending response from @NathanEckert) |
I am using the same version as you. |
The modern S3EC and SDK V2 treat reading 0 bytes from a stream differently in at least one case: If the Stream has no more content.
The modern S3EC and SDK V2 treat reading 0 bytes from a stream differently in at least one case: If the Stream has no more content.
The modern S3EC and SDK V2 treat reading 0 bytes from a stream differently in at least one case: If the Stream has no more content.
The modern S3EC and SDK V2 treat reading 0 bytes from a stream differently in at least one case: If the Stream has no more content.
@NathanEckert thank you for that reproduction. We probably were hitting your error, but the log statement was not emitting. I am seeing other issues as well. Much Obliged, |
Upon further investigation, this behavior is due to the implementation of the AWS SDK's |
Problem:
When using ranged queries with the encryption client, I get a different behavior than with the regular S3 client.
It is not clear there which one is incorrect:
java.io.InputStream#read(byte[], int, int)
implementation and javadocI do not know which behavior is the correct one, but i wanted to report it as it is an inconsistency and a bug that can arise while migrating to the new SDK.
The text was updated successfully, but these errors were encountered: