ppkarwasz opened a new pull request, #4160:
URL: https://github.com/apache/logging-log4j2/pull/4160
## Motivation
`NetUtils.toURI(String)` is the single entry point that turns a
configuration location (given as a URI or a file system
path) into a `URI`.
Its previous implementation mixed several special cases and behaved
inconsistently across platforms:
- an absolute UNIX path stayed a scheme-less URI while an absolute Windows
path became a `file:` URI,
- a Windows drive letter (`C:`) could be mistaken for a URI scheme,
- and a URL repaired for blanks silently lost its user-info, port and query.
This PR rewrites the method around two rules and isolates the awkward cases
in
one helper.
## Conversion logic
1. **Absolute URI** (a real scheme, not a single-letter Windows drive
letter) is returned **as commanded**, unchanged.
This covers `classpath:`, `file:`, `http(s):`, and Apache Commons VFS
URLs such as `zip:file:///a.zip!/log4j2.xml`.
2. Otherwise, the value is a **file system path**:
- an **absolute** path (as `File.isAbsolute()` judges it on the running
OS: a UNIX `/...` path, a Windows drive
`C:\...`/`C:/...`) becomes a `file:` URI holding the full path;
- a **relative** path becomes a **scheme-less** URI, to be resolved
later as a file or a class path resource.
> [!IMPORTANT]
>
> Log4j Core handles **relative** URIs specially: first it tries to resolve
the URI as a local file and falls back to a classpath lookup.
## Behavioral changes
The conversion outcome changes in the following cases. The before/after
values
below were captured by running the new test suite against the previous
implementation (`<cwd>` is the process working directory).
| Input | Before |
After | Note |
|-------------------------------|-------------------------------------|-------------------------------------|---------------------------------|
| `http://h/a b/x?env=prod x` | `http://h/a%20b/x` |
`http://h/a%20b/x?env=prod%20x` | query preserved |
| `https://user@h:8443/a b/x` | `https://h/a%20b/x` |
`https://user@h:8443/a%20b/x` | user-info and port preserved |
| `/path/without/spaces` (UNIX) | `/path/without/spaces` |
`file:/path/without/spaces` | absolute path now a `file:` URI |
| `C:/dir/log4j2.xml` (UNIX) | `C:/dir/log4j2.xml` (scheme `C`) |
`C%3A/dir/log4j2.xml` (scheme-less) | drive letter is not a scheme |
| `C:\dir\log4j2.xml` (UNIX) | `file:/<cwd>/C:%5Cdir%5Clog4j2.xml` |
`C%3A%5Cdir%5Clog4j2.xml` | relative path stays scheme-less |
| `D:\path\to\x` (UNIX) | `file:/<cwd>/D:%5Cpath%5Cto%5Cx` |
`D%3A%5Cpath%5Cto%5Cx` | relative path stays scheme-less |
Summarized:
1. **URL repair no longer drops components.** Blanks in an
`http(s)`/`ftp`/VFS URL are encoded while user-info, port and query are kept.
2. **An absolute UNIX path resolves to a `file:` URI**, matching the
existing Windows behavior, so absolute paths are symmetric across platforms.
3. **A Windows drive letter is never a URI scheme.** `C:/...` (and `C:\...`)
resolve to a `file:` URI on Windows (the drive) and to a scheme-less relative
URI on UNIX (the colon escaped), instead of a `scheme=C` URI or a
working-directory-resolved `file:` URI.
These are corner cases (remote URLs with blanks, drive-letter paths used on
the wrong OS, absolute UNIX config paths).
Common locations (`log4j2.xml`, `config/log4j2.xml`, `classpath:...`,
`file:...`, a plain absolute Windows path) are unaffected.
## Tests
`NetUtilsTest` is reworked into parameterized cases.
Every input runs on every OS; only the expected `toString()` differs,
selected through `SystemUtils.IS_OS_WINDOWS`.
The commits are ordered tests-first:
- the first commit adds the tests (failing against the old behavior, which
is how the table above was produced),
- the second commit applies the fix.
## Follow-up
A `src/changelog/.2.x.x/*.xml` entry still needs to be added for these
behavioral changes before merge.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
