[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
-----------------------------------
Description:
Hello,
I'm contacting you because I'm experiencing a problem that seems to be a bug
when calling a REST service in multipart mode via jarxr-client in proxy mode.
I'm working with version 3.1.4 but I've also tested with version 3.5.7 (Unable
to use a more recent version for technical reasons).
h2. Description of the problem:
h3. Current code:
I have an interace containing the following signature:
{code:java}
@Consumes({ "multipart/form-data" })
@Produces({ "application/json" })
FileId create(MultipartBody body);
{code}
Then code to call the service (code from an integration test):
{code:java}
@Resource(name = "myApi") // defined in a spring context with jaxrs:client
private MyApi api;
@Test
public void addContent() {
final Attachment file = new Attachment("file",
MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
final MultipartBody body = new MultipartBody(file);
final FileId result = api.create(body);
assertNotNull(result);
}
{code}
h3. Result obtained:
I obtain the following trace:
{noformat}
INFOS: Outbound Message
---------------------------
ID: 1
Address: https://XXXXXXXXXXXXXXXXXX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
XXXXXXXXXXXXXXXXXXXX]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <file>
TEST
--uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
{noformat}
... and the webservice response:
{noformat}
--------------------------------------
févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
INFOS: Inbound Message
----------------------------
ID: 1
Response-Code: 500
Encoding: ISO-8859-1
Content-Type: application/json
Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
09:02:50 GMT], expires=[0], pragma=[no-cache],
x-content-type-options=[nosniff], x-frame-options=[DENY], x-xss-protection=[1;
mode=block]}
Payload: {"type":"XXXXX","title":"Unhandled Error","status":500,"detail":"Maybe
more than one part sent, epilogue is not empty, or CRLF is missing before end
delimiter ? 4 bytes read for file part but 2 expected according to
content-length header."}
{noformat}
After a bit of digging, I realized that the problem lies in the
writeAttachments method of the AttachmentSerializer class:
{code:java}
StringWriter writer = new StringWriter();
writer.write("\r\n--");
writer.write(bodyBoundary);
writer.write("--"); // <--- HERE
out.write(writer.getBuffer().toString().getBytes(encoding));
out.flush();
{code}
I was able to correct my problem locally by making this correction:
{code:java}
StringWriter writer = new StringWriter();
writer.write("\r\n--");
writer.write(bodyBoundary);
writer.write("--\r\n"); // <------ fixing her
out.write(writer.getBuffer().toString().getBytes(encoding));
out.flush();
{code}
And the call succeeds with a 201 code and a JSON response as expected
However, I'm dubious about stumbling across such an error, so I wonder if I've
missed something?
Sincerely
was:
Hello,
I'm contacting you because I'm experiencing a problem that seems to be a bug
when calling a REST service in multipart mode via jarxr-client in proxy mode.
I'm working with version 3.1.4 but I've also tested with version 3.5.7 (Unable
to use a more recent version for technical reasons).
h2. Description of the problem:
h3. Current code:
I have an interace containing the following signature:
{code:java}
@Consumes({ "multipart/form-data" })
@Produces({ "application/json" })
FileId create(MultipartBody body);
{code}
Then code to call the service (code from an integration test):
{code:java}
@Resource(name = "myApi") // defined in a spring context with jaxrs:client
private MyApi api;
@Test
public void addContent() {
final Attachment file = new Attachment("file",
MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
final MultipartBody body = new MultipartBody(file);
final FileId result = api.create(body);
assertNotNull(result);
}
{code}
h3. Result obtained:
I obtain the following trace:
{noformat}
INFOS: Outbound Message
---------------------------
ID: 1
Address: https://XXXXXXXXXXXXXXXXXX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
XXXXXXXXXXXXXXXXXXXX]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <fichier>
TEST
--uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
{noformat}
... and the webservice response:
{noformat}
--------------------------------------
févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
INFOS: Inbound Message
----------------------------
ID: 1
Response-Code: 500
Encoding: ISO-8859-1
Content-Type: application/json
Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
09:02:50 GMT], expires=[0], pragma=[no-cache],
x-content-type-options=[nosniff], x-frame-options=[DENY], x-xss-protection=[1;
mode=block]}
Payload: {"type":"XXXXX","title":"Unhandled Error","status":500,"detail":"Maybe
more than one part sent, epilogue is not empty, or CRLF is missing before end
delimiter ? 4 bytes read for file part but 2 expected according to
content-length header."}
{noformat}
After a bit of digging, I realized that the problem lies in the
writeAttachments method of the AttachmentSerializer class:
{code:java}
StringWriter writer = new StringWriter();
writer.write("\r\n--");
writer.write(bodyBoundary);
writer.write("--"); // <--- HERE
out.write(writer.getBuffer().toString().getBytes(encoding));
out.flush();
{code}
I was able to correct my problem locally by making this correction:
{code:java}
StringWriter writer = new StringWriter();
writer.write("\r\n--");
writer.write(bodyBoundary);
writer.write("--\r\n"); // <------ fixing her
out.write(writer.getBuffer().toString().getBytes(encoding));
out.flush();
{code}
And the call succeeds with a 201 code and a JSON response as expected
However, I'm dubious about stumbling across such an error, so I wonder if I've
missed something?
Sincerely
> Missing \r\n in multipart request
> ---------------------------------
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.4, 3.5.7
> Reporter: Guillaume Chauvet
> Priority: Major
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---------------------------
> ID: 1
> Address: https://XXXXXXXXXXXXXXXXXX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> XXXXXXXXXXXXXXXXXXXX]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID: <file>
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --------------------------------------
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
> ----------------------------
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"XXXXX","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <------ fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
