I've revisited this and I am still seeing what is perceived to be improperly encoded queryparams, even after finding the docs that are supposed to control this behavior in ProxyEndpoint configuration elements.
I tried changing the property and various tests with no ability to correct the behavior.
<HTTPProxyConnection>
<BasePath>/notarget</BasePath>
<Properties>
<Property name="request.queryparams.ignore.content.type.charset">true</Property>
</Properties>
</HTTPProxyConnection>
I am always seeing the "request.queryparam.email" variable with a value of "kurt any@foo.com" when I send "?email=kurt+any@foo.com" no matter what I send in content-type header.
After further digging, the root cause is the underlying Java URLDecoder.decode function. Given the following test code:
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.io.UnsupportedEncodingException; // Import the exception class
import java.nio.charset.StandardCharsets;
public class UrlEncodeDecodeExample {
public static void main(String[] args) {
String encodedValue = "name+suffix@any.com";
try {
System.out.println(); // Add a blank line for better readability
String defaultEncodedValue = URLEncoder.encode(encodedValue, StandardCharsets.UTF_8.toString());
System.out.println("Encoded incorrectly encoded value: " + encodedValue + " becomes: " + defaultEncodedValue);
System.out.println(); // Add a blank line for better readability
// Decoding with UTF-8, which is generally recommended
String decodedValue = URLDecoder.decode(encodedValue, StandardCharsets.UTF_8.toString());
System.out.println("Incorrectly encoded value: " + encodedValue);
System.out.println("Decoded incorrectly encoded value: " + decodedValue);
} catch (UnsupportedEncodingException e) {
// This catch block handles the exception if the charset is not supported
System.err.println("Error: The specified encoding is not supported.");
e.printStackTrace(); // Print the stack trace for debugging
}
System.out.println(); // Add a blank line for better readability
String correctlyEncodedValue = "name%2Bsuffix%40any.com"; // %2B for +, %40 for @
try {
System.out.println(); // Add a blank line for better readability
String correctlyDecodedValue = URLDecoder.decode(correctlyEncodedValue, StandardCharsets.UTF_8.toString());
System.out.println("Correctly encoded value: " + correctlyEncodedValue);
System.out.println("Decoded correctly decoded value: " + correctlyDecodedValue);
} catch (UnsupportedEncodingException e) {
// This catch block handles the exception for the second decode call
System.err.println("Error: The specified encoding is not supported.");
e.printStackTrace();
}
}
}
Running that test case produces the output:
Encoded incorrectly encoded value: name+suffix@any.com becomes: name%2Bsuffix%40any.com
Incorrectly encoded value: name+suffix@any.com
Decoded incorrectly encoded value: name suffix@any.com
Correctly encoded value: name%2Bsuffix%40any.com
Decoded correctly decoded value: name+suffix@any.com
Bottom line, to use a literal '+' character in a query param value percent encode it as '%2B'.
References: RFC 3986 and RFC 1866.
LinkedIn
Twitter
