SMB components fail to access files with spaces in its path due to duplicate URL encoding

[smitsjelle]

In what version(s) of Spring Integration are you seeing this issue?
6.4.0 & 6.2.1 (likely affects older versions too, but tested on these)

Describe the bug

When attempting to connect to an SMB share where either the 'share and dir', the 'remote directory' or the file name contains a whitespace, this will be URL-encoded to %20. It appears that the URL encoding is applied twice, both by Spring integration as well as by the underlying codelibs/jcifs library.

Essentially, in SmbShare, Spring calls the constructor of its parent jcifs.smb.SmbFile with the String url argument (sidenote: this contructor appears to be deprecated). To obtain the URL string, SmbConfig#209 creates an URI from it, an returns the ASCIIString that maintains the URL encoding. The parent class subsequently creates an URL object out of this already URL-encoded String.

This appears to cause double encoding, resulting in e.g. an outbound channel adapter with auto create directory true creating the directory space%20directory instead of the provided argument space directory

To Reproduce

Using the existing Spring integration unit tests, this can easiliy be reproduced. In SmbTestSupport, change SHARE_AND_DIR to smb share, and error will occur. Subsequently change the output of SmbConfig#toUrl() to a non-url-encoded String (e.g. by replacing line 209 with return "smb://%s@%s/%s".formatted(domainUserPass, getHostPort(), path); and it will succeed.

Though the line above seems to solve it for this specific case, I have not tested thoroughly on other edge cases, and I am not sure whether there are valid considerations why we would still need to use the URI.toAsciiString call for other reasons. I feel a part of it may already be handled as the call to StringUtils.cleanPath().

Expected behavior

Even though I'd like to be able to 'fix' the underlying directories so they do not contain whitespaces, I'd like to be able to access those directories, as it appears to be supported by the libarary and now just fails because double URL encoding.

[artembilan]

I think your investigation is correct: we must not set an encoded string into an URL constructor.

Please, consider to contribute the fix: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc