This Pull Request results from a debugging call with one of k6's users.
Problem
They were experiencing issues relating to:
Putting objects whose objectKey would contain space characters.
Signature path argument would not automatically add a leading slash if missing, leading to erroneous URLs
The new Endpoint type involved in the signature process is exposed by the signature.js bundle but not the overarching aws.js one.
Solution
To address these issues, this PR applies the following changes:
We set the S3Client signer's uriEscapePath attribute to true, to ensure paths are always double URI encoded in S3 paths.
The SignatureV4.sign and SignatureV4.presign operations ensure that a leading slash is appended to the target URL (if not present) when generating the resulting URL. That way we avoid potentially generating malformed URLs such as https://s3.amazonaws.commy-bucket/object-key as we've seen happen.
We expose the Endpoint type from the index.ts entry point, making it available in the aws.js bundle.
Next steps
In order to unblock our user, I'll publish a v0.12.1 once this is merged.
This Pull Request results from a debugging call with one of k6's users.
Problem
They were experiencing issues relating to:
Endpointtype involved in the signature process is exposed by thesignature.jsbundle but not the overarchingaws.jsone.Solution
To address these issues, this PR applies the following changes:
S3Clientsigner'suriEscapePathattribute totrue, to ensure paths are always double URI encoded in S3 paths.SignatureV4.signandSignatureV4.presignoperations ensure that a leading slash is appended to the target URL (if not present) when generating the resulting URL. That way we avoid potentially generating malformed URLs such ashttps://s3.amazonaws.commy-bucket/object-keyas we've seen happen.Endpointtype from theindex.tsentry point, making it available in theaws.jsbundle.Next steps
In order to unblock our user, I'll publish a
v0.12.1once this is merged.