- Newest
- Most votes
- Most comments
you dont say which API call/step is giving the error, nor how you generated the checksum to compare, nor which S3 attribute you are checking, nor exactly what you are signing with the "pre-signed URL". When doing multipart -- OR when the size of the upload is large enough, the "E-TAG" of the assembled file on S3 may not be the same as a simple MD5 of the original file. You need to do checksums of each piece uploaded in order to calculate the ETAG of the entire object in S3. It may not be possible to use a presigned URL for MultiPart uploads -- each PART is distinct and requires its own signing.
The upload part request fails: https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html with the message "The request signature we calculated does not match the signature you provided."
Checksum is set in Content-MD5 and is correct, I double checked using md5sum. Also this issue doesn't happen with other files, just some executables.
Relevant content
asked 2 years ago- asked a year ago
AWS OFFICIALUpdated 8 months ago- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated a year ago
Could you check if the MD5 hash generated using the Angular application is the same as the one generated in your computer? (see this https://aws.amazon.com/premiumsupport/knowledge-center/data-integrity-s3/).
If they are the same, please, share the code you are using to upload the file.
S3 doesn't do any distinction between file types.
I double checked the MD5 using md5sum and it's correct. If it wasn't I would also expect all the files to fail. What happens is that only some executable files fail to upload.
In the end we gave up on this and we're just using a lambda to calculate the checksum for the entire file after upload. We need this for other reasons anyway.