-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
S3: fix Checksum behavior for GetObject with PartNumber #12842
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
Conversation
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 1h 26m 21s ⏱️ Results for commit 548a460. ♻️ This comment has been updated with latest results. |
100014e
to
548a460
Compare
LocalStack Community integration with Pro 2 files 2 suites 1h 3m 32s ⏱️ Results for commit 548a460. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Interesting use-case 🤔
Motivation
As reported by #12840, we did not return the right Checksum when calling
GetObject
withPartNumber
when the multipart upload was created with aCOMPOSITE
checksum type. It should have returned the part checksum. But if the objects were made of several parts, it would have returned no checksum at all. If the object only had one part, it would have returned the object checksum, which was wrong.This PR fixes the behavior. As a side-note, it seems S3 has quite special cases around checksums, and since they implemented
COMPOSITE
&FULL_OBJECT
, the codebase became quite a bit more complex 😕Changes
ChecksumType=COMPOSITE
, properly return the part checksum when requested withGetObject
andHeadObject
COMPOSITE
andFULL_OBJECT
COMPOSITE
returns the part checksum and not the composite checksum of the objectFULL_OBJECT
returns the part checksum which is equal to the object checksumCOMPOSITE
andFULL_OBJECT
COMPOSITE
returns the part checksumFULL_OBJECT
does not return the part checksum, even though thelist_parts
call earlier showed the part had a checksumfixes #12840