Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Download component doesn't work when + character is in filename #2862

Open
juw177 opened this issue Sep 24, 2024 · 1 comment
Open

Download component doesn't work when + character is in filename #2862

juw177 opened this issue Sep 24, 2024 · 1 comment

Comments

@juw177
Copy link

juw177 commented Sep 24, 2024

  1. Upload a file to DAM with a + character in the file name
  2. Use this in the Download component
  3. The link comes up as broken
@ky940819
Copy link
Contributor

ky940819 commented Oct 8, 2024

For reference.

This issue is caused by line 180 here:

private @NotNull Link buildLink(String path, SlingHttpServletRequest request, Map<String, String> htmlAttributes) {
if (StringUtils.isNotEmpty(path)) {
try {
path = LinkUtil.decode(path);
} catch (Exception ex) {
String message = "Failed to decode url '{}': {}";
if (LOGGER.isDebugEnabled()) {
LOGGER.warn(message, path, ex.getMessage(), ex);
} else {
LOGGER.warn(message, path, ex.getMessage());
}
}

The path is decoded by the LinkBuilder. In your case the + symbol is decoded into a space.
Later, the path is re-encoded and the space is converted into %20 (as would be proper for a space).

The addition of this pre-decoding was done here:
87a8c2a

If I understand the change correctly, then the purpose was to handle situations where the link may come from author-input data and may already be encoded (i.e. a button where an author copy/pasted a link - which is reasonable for them to do). If the URL were not to be decoded, then it would end up double-encoded.

Ideally this wouldn't happen when the link is coming from a resource path (i.e. a page, asset, etc) because we know it's not already encoded.

This specific case could probably be eliminated by using a URL decoding method that adheres to RFC2396.
The java.net.URLDecoder utility states This class contains static methods for decoding a String from the application/x-www-form-urlencoded MIME format (see https://docs.oracle.com/javase/8/docs/api/java/net/URLDecoder.html).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants