Jonathan Gallimore created CXF-8619:
---------------------------------------
Summary: Potential double-urldecode of @Form parameters
Key: CXF-8619
URL: https://issues.apache.org/jira/browse/CXF-8619
Project: CXF
Issue Type: Bug
Affects Versions: 3.4.5
Reporter: Jonathan Gallimore
Fix For: 3.5.0, 3.4.6
Where form parameters are retrieved via HttpServletRequest.getParameter methods
([https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/FormUtils.java#L176-L180)],
the key and value are already URL decoded.
They are then subsequently decoded again:
[https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1172-L1178]
The effect here is that an endpoint like this:
{code:java}
@POST
@Path("/api")
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
@Produces(MediaType.TEXT_PLAIN)
public Response myWebService(@Context HttpServletRequest request, @Context
HttpServletResponse res, @FormParam("p1") String p1) {
LOGGER.info("Value received: " + p1);
return Response.ok(p1).build();
}{code}
if called with a payload of
p1=hello%2bworld
would receive "hello world" and not "hello+world".
This has been observed when running in Apache TomEE, when running with a
servlet filter that also calls HttpServletRequest.getParameter(). The effect
here is that Tomcat consumes the request inputstream, parses the form data and
populates a parameter map. In turn, when the call propagates to CXF, the
inputstream is empty, so it falls back to the servlet parameters (which have
already been urldecoded).
PR with a test to follow, and I'll follow up on the mailing list too.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
