CloudFront signed URLs fail when they include `filename*=UTF-8''`

[MarquisLP]

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

As per the Content-Disposition specification, a UTF-8 encoded filename can be set for links with the attachment disposition by including filename*=UTF-8''{encodedFilename} in the value for response-content-disposition in the query string.

However, when this addition is made to a URL and then passed to cloudfront-signer's getSignedUrl(), the resulting signed URL fails on load with an Access Denied error.

Regression Issue

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

SDK version number

@aws-sdk/cloudfront-signer@3.1046.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v24.4.1

Reproduction Steps

Generate a signed URL that includes filename*:

const signer = require('@aws-sdk/cloudfront-signer');

const filename = '文件';
const normalizedFilename = normalizeHelperFunction(filename);
const encodedFilename = encodeURIComponent(filename);

const signedUrl = signer.getSignedUrl({
    url: `https://example.com/path?response-content-disposition=attachment;filename=${normalizedFilename};filename*=UTF-8''${encodedFilename}`,
});

return signedUrl;

Take that signed URL and attempt to load it in a web browser.

Observed Behavior

The signed URL redirects to an error page with an Access Denied error.

Expected Behavior

The signed URL loads the requested file for download.

Possible Solution

Add special handling of the UTF-8'' part of the filename* option so that apostrophes are allowed to be included unencoded there. (See the Additional Information/Context below.)

Additional Information/Context

There was a similar issue in the past: #7470.

However, where that past issue was caused by encoding issues with the asterisk * in filename*, this current issue appears to be related to the apostrophes in UTF-8''. If the apostrophes are percent encoded, turning that part into UTF-8%27%27, then the resulting signed URL loads successfully.

However, this is not an ideal solution because there is inconsistent behaviour on how UTF-8%27%27 is handled between browsers on file download:

• Chrome: Properly decodes filename*
• Firefox: Properly decodes the filename, but misinterprets the UTF-8'' part as a literal string and includes it in the filename as a prefix
• Edge: Properly decodes filename*
• Safari: Does not parse filename*, likely due to a failing check on the value, and falls back to filename

[kuhe]

A fix was released with https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.1074.0.

https://www.npmjs.com/package/@aws-sdk/cloudfront-signer/v/3.1074.0

This should address the 403, but won't necessarily have an effect on how some browsers interpret the response.

[MarquisLP]

We've confirmed that this issue is fixed as of 3.1074.0.

One detail we discovered is that the value after UTF-8'' needs to be double-encoded (for example filename*%3DUTF-8%27%27%E6%96%87%E4%BB%B6.mp4 --> filename*%3DUTF-8%27%27%25E6%2596%2587%25E4%25BB%25B6.mp4), otherwise the signed URL will fail with Access Denied.

After double-encoding, the signed URL works and file downloads have the correct filename across all browsers.

Thank you for the quick fix. Closing this issue as resolved.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.