[jira] [Created] (NIFI-16000) FileUtils.getSanitizedFilename rejects filenames containing spaces

["Matt Gilman (Jira)" <ji...@apache.org>]

Matt Gilman created NIFI-16000:
----------------------------------

             Summary: FileUtils.getSanitizedFilename rejects filenames containing spaces
                 Key: NIFI-16000
                 URL: https://issues.apache.org/jira/browse/NIFI-16000
             Project: Apache NiFi
          Issue Type: Improvement
          Components: Core Framework
            Reporter: Matt Gilman
            Assignee: Matt Gilman


`org.apache.nifi.util.file.FileUtils.getSanitizedFilename(String)` treats the space character (code point `32`) as invalid and replaces it with an underscore. This list was originally derived from a cross-platform "invalid filename characters" reference, but the space character is legal on every major file system (NTFS, ext4, APFS, etc.).

This becomes a usability problem because of how the method is consumed. Both `ConnectorResource` and `ParameterContextResource` use it as a strict validation gate for the asset name supplied in the `Filename` request header:

{code:java}
final String sanitizedAssetName = FileUtils.getSanitizedFilename(assetName);
if (!assetName.equals(sanitizedAssetName)) {
    throw new IllegalArgumentException(FILENAME_HEADER + " header contains an invalid file name");
}
{code}

Because any name containing a space is rewritten during sanitization, the equality check fails and the upload is rejected. As a result, common, perfectly valid filenames cannot be uploaded as assets. For example, a file produced by browser/OS download de-duplication such as {{driver (1).jar}} is sanitized to {{driver_(1).jar}}, which differs from the original and is therefore rejected with _"... header contains an invalid file name."_

**Proposed change**

Permit spaces within a filename while keeping the result canonical and file-system-safe:

* Remove the space character (`32`) from the invalid-character set so interior spaces are preserved.
* After the existing per-character replacement, normalize the result by collapsing interior whitespace runs to a single space, stripping leading/trailing whitespace, and removing trailing dots.

This preserves the existing "sanitize, then reject if the name changed" contract at the call sites (a non-canonical name such as a leading/trailing space or a trailing dot is still rejected), while allowing legitimate names that merely contain interior spaces. It also avoids the ambiguous edge cases that simply accepting spaces would introduce (leading/trailing spaces, repeated spaces, trailing dots, and whitespace-only names — the latter of which can collide on Windows, where trailing spaces/dots are silently stripped).

**Examples (after change)**

| Input | Output | Accepted by callers? |
| {{driver (1).jar}} | {{driver (1).jar}} | Yes |
| {{driver   (1).jar}} (repeated spaces) | {{driver (1).jar}} | No (non-canonical) |
| {{ driver (1).jar }} (leading/trailing) | {{driver (1).jar}} | No (non-canonical) |
| {{report...}} (trailing dots) | {{report}} | No (non-canonical) |
| {{a/b\c}} | {{a_b_c}} | No (non-canonical) |

**Backward compatibility**

The change is backward compatible: names that previously sanitized cleanly continue to do so, and the only behavioral change is that filenames whose sole issue was an interior space are now accepted instead of being rewritten.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)