[ 
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Chauvet updated CXF-8975:
-----------------------------------
    Priority: Critical  (was: Major)

> Missing ending CRLF 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: Critical
>
> 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)

Reply via email to