cloudfront-signer regression - change in signature from getSignedUrl when query params have spaces

[rswheeldon]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

In #8033 it was reported that there was a regression in that URLs with special characters in the filenames now generated signed URLs which failed verification and errored with 403 AccessDenied message.

This was correct, and fixed in #7763 and released in 3.1056.0 (or possibly earlier but that's the earliest I can download via npm that exhibits the fix).

However, this introduced a second regression in that if the URL parameter has a space (+) in it, such as response-content-disposition=inline; filename*=filename.pdf;
or response-content-disposition=inline; "My file.pdf"; then it breaks and produces a URL which exhibits the same 403 Request denied behaviour as described in the earlier issue.

Regression Issue

• Select this option if this issue appears to be a regression.

SDK version number

"@aws-sdk/cloudfront-signer": "3.1056.0"

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v24.13.0

Reproduction Steps

This test if added to packages/cloudfront-signer/src/sign.ts passes in v3.1034.0 just before the regression and fails afterwards. The only change is in the signature part of it so I'm not sure what the internal issue is.

  it("should give me the same signature as it previously did", () => {
    const url = new URL("http://example.com/path/to/file.pdf");
    url.searchParams.set("response-content-disposition", "inline; filename*=filename.pdf");
    const href = url.toString();
    expect(href).toContain("inline%3B+filename*%3Dfilename.pdf");
    expect(href).toBe(
      "http://example.com/path/to/file.pdf?response-content-disposition=inline%3B+filename*%3Dfilename.pdf",
    );
    const result = getSignedUrl({
      url: href,
      keyPairId,
      dateLessThan,
      privateKey,
      passphrase,
    });
    expect(result).toBe(
      "http://example.com/path/to/file.pdf?response-content-disposition=inline%3B%20filename*%3Dfilename.pdf&Expires=1577836800&Key-Pair-Id=APKAEIBAERJR2EXAMPLE&Signature=JBs7DvOuSvgzWJQS~I03~90rFF-yVftF9gNpKd9TrRXrs6oLMITJ7htEnL2RU4XnZWx9-RY5uudGMIOCgkDGSmlmpk2-DXykCq00ZhRdawHHFIMOm~lc-e0ARIxWkcdRvyNBNsGJphyrPZIkcmWKHqlUUIi75gkjKCugcB96T09vjdEQ-rPVE-TYkF5RUjGVRBb8VLZHzC5nQsnf2nLi9-u4mCaq4obNWT1cGsIUJ3I4JbNd8N2nG5O3u0Y10Kye3HRkCstSBgqPX56CZqxFxUxIbcCrHgQUYTzQe60e76oqYPfk3ItRV4Ec3lan07gmO4e~zRp4xKN9wUmZm0sGMg__",
    );
  });

Observed Behavior

I expect signed URLs to still be valid and for the signatures generated given the testcase input to be consistent over time.

Expected Behavior

We experienced 403 errors and the test case above demonstrates an unexpected change in behaviour

Possible Solution

I suspect its related to the URL encoding.

Additional Information/Context

No response