Error: Non-file stream objects are not supported with SigV4 when using s3.uploadPart()
See original GitHub issueI get the following error:
Non-file stream objects are not supported with SigV4
when passing a FileStream
to s3.uploadPart()
.
Oddly I don’t get the error if I swap s3.uploadPart()
for s3.upload()
- this leads me to believe my object is a valid file stream.
Issue Analytics
- State:
- Created 7 years ago
- Comments:17 (5 by maintainers)
Top Results From Across the Web
Node file upload error in Amazon s3 - Stack Overflow
You should pass the upload method a file. Here is an example: var file = files[0]; var fileName = file.name; var albumPhotosKey ...
Read more >Amazon S3 Signature Version 4 Authentication Specific Policy ...
Identifies the version of AWS Signature that you want to support for authenticated requests. For authenticated requests, Amazon S3 supports both Signature ......
Read more >upload-part — AWS CLI 2.9.10 Command Reference
To upload a part from an existing object, you use the UploadPartCopy operation. You must initiate a multipart upload (see CreateMultipartUpload ) before...
Read more >Chapter 2. Ceph Object Gateway and the S3 API
To use encryption, client requests MUST send requests over an SSL connection. Red Hat does not support S3 encryption from a client unless...
Read more >Uploads a part in a multipart upload — s3_upload_part • paws
If they do not match, Amazon S3 returns an error. If the upload request is signed with Signature Version 4, then Amazon Web...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@PsyTae With version 2.4.0, the S3 client was updated to use Sigv4 by default. It’s still possible to use Sigv2 by specifying you want to use that when instantiating your client:
This issue should only occur when using
signatureVersion: v4
due to how the body is signed. Can you share how your input stream is created?The stream is created by
Busboy
https://github.com/mscdex/busboy and I just pass it as is to s3Note that if I build the incoming busboy stream in memory before handing it to
s3.uploadPart()
it works fine:The stream is created by
Busboy
https://github.com/mscdex/busboy and I just pass it as is to s3 - but that’s just to slow and memory intensive.