plusplusjiajia opened a new pull request, #821:
URL: https://github.com/apache/paimon-rust/pull/821
## The bug
Java's `RESTAuthParameter` constructor URL-encodes every parameter value,
so the signer sees the encoded form:
```java
this.parameters.put(entry.getKey(), encodeString(entry.getValue()));
The Rust port of that type stores the values raw, while the HTTP client
still percent-encodes them on the way out. The client therefore signs one
string and sends another, and DLF answers HTTP 401 for any value containing a
character outside [A-Za-z0-9*-._]. Measured against a real DLF catalog,
databaseNamePattern of %, db%, a:b, a/b, a b, a+b, a=b and dt=2026-07-22/% all
failed, while plain and a*b passed — and the Java client passed on every one of
them. Every *NamePattern filter takes a % wildcard, so this reaches shipping
call sites.
The mock server used by the test suite does not verify signatures, which
is why no existing test catches it.
The fix
Restore the encoding in RESTAuthParameter::new, where Java does it, so
every signer inherits it. Values are encoded; keys are left alone, as in Java.
The DLF4 canonical-query construction is untouched — only its input was wrong.
DLFOpenApiSigner decodes those values back out, so its two
urlencoding::decode calls become RESTUtil::decode_string, which turns + back
into a space as Java's decodeString does. That drops the last use of
urlencoding, so the dependency goes too. RESTApi also stops pre-encoding the
warehouse value, which would otherwise now be encoded twice.
--
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]
