You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Graham Leggett (Jira)" <ji...@apache.org> on 2022/06/01 14:34:00 UTC
[jira] [Created] (CXF-8709) cxf-wadl2java-plugin: Consume "multipart/form-data" triggers 415 Unsupported Media Type
Graham Leggett created CXF-8709:
-----------------------------------
Summary: cxf-wadl2java-plugin: Consume "multipart/form-data" triggers 415 Unsupported Media Type
Key: CXF-8709
URL: https://issues.apache.org/jira/browse/CXF-8709
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.5.2
Reporter: Graham Leggett
When an attempt is made to use the cxf-wadl2java-plugin against the wadl below, the generated method is never matched by jersey, which always returns "415 Unsupported Media Type".
{code}
<method name="POST" id="postArchivePaymentNote">
<doc>Post an archive document to a paymentnote.</doc>
<request>
<representation mediaType="multipart/form-data">
<doc>Uploaded files.</doc>
</representation>
<param name="Expect" style="header" type="xsd:string">
<doc>Expect header requesting permission to upload as described in https://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1</doc>
</param>
<param name="Authorization" style="header" type="xsd:string">
<doc>Authorization header containing username as described in https://www.ietf.org/rfc/rfc2617.txt (Basic Authentication)</doc>
</param>
<param name="Accept" style="header" type="xsd:string">
<doc>Accept header containing the requested variant as described in https://www.ietf.org/rfc/rfc2616.txt</doc>
</param>
<param name="Origin" style="header" type="xsd:string">
<doc>Origin header containing the CORS origin URL as described in https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS</doc>
</param>
</request>
<response status="200">
<representation mediaType="application/xml" element="signatureservice:signatureservice">
<doc>Return the signatureservice:signatureservice element on success</doc>
</representation>
<representation mediaType="application/json" element="signatureservice:signatureservice">
<doc>Return the signatureservice:signatureservice element on success</doc>
</representation>
<representation mediaType="text/plain">
<doc>Return plain text result on success</doc>
</representation>
<doc>Browse a specific result.</doc>
</response>
<response status="400">
<representation mediaType="application/xml" element="signatureservice:signatureservice" />
<representation mediaType="application/json" element="signatureservice:signatureservice" />
<representation mediaType="text/plain"/>
<doc>Invalid input strings, error message returned in "error" property</doc>
</response>
<response status="403">
<representation mediaType="application/xml" element="signatureservice:signatureservice" />
<representation mediaType="application/json" element="signatureservice:signatureservice" />
<representation mediaType="text/plain"/>
<doc>If forbidden, 403</doc>
</response>
<response status="404">
<representation mediaType="application/xml" element="signatureservice:signatureservice" />
<representation mediaType="application/json" element="signatureservice:signatureservice" />
<representation mediaType="text/plain"/>
<doc>Result not found</doc>
</response>
</method>
{code}
The following interface is generated:
{code}
@POST
@Consumes("multipart/form-data")
@Produces({"application/xml", "application/json", "text/plain" })
@Path("/paymentnote/{paymentnote}")
void postArchivePaymentNote(@PathParam("paymentnote") String paymentnote, @HeaderParam("Expect") String expect, @HeaderParam("Authorization") String authorization, @HeaderParam("Accept") String accept,
@HeaderParam("Origin") String origin, MultipartBody body, @Suspended AsyncResponse async);
{code}
Removing async makes no difference, a MultipartBody body on it's own still does not match.
One of the side effects of the generated interface is that it seems the body is read into RAM/disk cache before being passed for processing, which is a DoS vector.
Has multipart support ever been shown to work with cxf-wadl2java-plugin?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)