Ruiqi Dong created CODEC-338:
--------------------------------
Summary: PercentCodec loses literal '+' when plusForSpace is
enabled
Key: CODEC-338
URL: https://issues.apache.org/jira/browse/CODEC-338
Project: Commons Codec
Issue Type: Bug
Reporter: Ruiqi Dong
*Summary*
When PercentCodec is configured with plusForSpace = true, it encodes spaces as
'+' but does not percent-escape an existing literal '+'. This makes the
encoding ambiguous: * original '+' is emitted as '+'
* original space is also emitted as '+'
During decoding, both are converted back to spaces, so decode(encode(x)) is no
longer a round-trip for inputs containing '+'.
*Affected code*
File: src/main/java/org/apache/commons/codec/net/PercentCodec.java
{code:java}
if (b == ESCAPE_CHAR) {
...
} else if (plusForSpace && b == '+') {
buffer.put((byte) ' ');
} else {
buffer.put(b);
} {code}
{code:java}
if (willEncode && canEncode(b)) {
...
} else if (plusForSpace && b == ' ') {
buffer.put((byte) '+');
} else {
buffer.put(b);
} {code}
The decoder treats '+' as a space when plusForSpace is enabled, but the encoder
does not force a literal '+' through %2B.
*Reproducer*
Add the following test to
src/test/java/org/apache/commons/codec/net/PercentCodecTest.java:
{code:java}
@Test
void testPercentEncoderDecoderWithLiteralPlusAndPlusForSpace() throws Exception
{
final String input = "a+b c";
final PercentCodec percentCodec = new PercentCodec(null, true);
final byte[] encoded =
percentCodec.encode(input.getBytes(StandardCharsets.UTF_8));
final String encodedS = new String(encoded, StandardCharsets.UTF_8);
assertEquals("a%2Bb+c", encodedS, "Literal plus must be escaped when
plusForSpace is enabled");
final byte[] decode = percentCodec.decode(encoded);
assertEquals(input, new String(decode, StandardCharsets.UTF_8),
"Round-trip with literal plus should preserve the original input");
} {code}
Run:
{code:java}
mvn -q
-Dtest=org.apache.commons.codec.net.PercentCodecTest#testPercentEncoderDecoderWithLiteralPlusAndPlusForSpace
test {code}
Observed behavior:
{code:java}
expected: <a%2Bb+c> but was: <a+b+c> {code}
The test fails on the encoding assertion, because the encoded form is 'a+b+c',
decoding it yields 'a b c', so the original literal '+' is lost.
Expected behavior:
When plusForSpace is enabled: * spaces may be emitted as '+'
* a literal '+' must be emitted as '%2B
That preserves round-trip behavior and keeps the encoded representation
unambiguous.
This is a public API semantic inconsistency inside the same codec
configuration. The encoder and decoder disagree on the meaning of '+': *
decoder: '+' means space
* encoder: '+' may mean either original '+' or original space
As a result, PercentCodec corrupts valid input containing plus signs under a
documented configuration mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
