[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815956#comment-17815956
]
Guillaume Chauvet commented on CXF-8962:
hello [~reta] ,
Works for me with 3.5.7 and 3.3.13. However, we're going to put our version
3.1.x problem on hold, as our supplier will be updating its technical stack in
the next update (we are stuck by this).
Thanks for everything,
Regards
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet closed CXF-8975.
--
Resolution: Not A Bug
Issue from webservice side
> 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: 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://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> 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":"X","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)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
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://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> 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":"X","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)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
---
Summary: Missing ending CRLF in multipart request (was: Missing \r\n in
multipart request)
> 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: 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://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> 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":"X","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)
[jira] [Updated] (CXF-8975) Missing \r\n in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
---
External issue URL: https://github.com/apache/cxf/pull/1674
Flags: Patch
> 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://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> 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":"X","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)
[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813667#comment-17813667
]
Guillaume Chauvet edited comment on CXF-8962 at 2/2/24 1:09 PM:
Same issue on versions 3.1.4 to 3.5.7:
{noformat}
Address: https://
Http-Method: DELETE
Content-Type:
Headers: {Accept=[text/plain] }
{noformat}
was (Author: gchauvet):
Same issue on versions 3.1.4 to 3.5.7:
{noformat}
Address: https://
Http-Method: DELETE
Content-Type:
Headers: {Accept=[text/plain] }
{noformat}
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813667#comment-17813667
]
Guillaume Chauvet commented on CXF-8962:
Same issue on versions 3.1.4 to 3.5.7:
{noformat}
Address: https://
Http-Method: DELETE
Content-Type:
Headers: {Accept=[text/plain] }
{noformat}
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no content, CXF will
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
> "text/xml" as fallback if no content type can be computed.
> The old implementation {{URLConnectionHTTPConduit}} called a
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method
> allowed to omit the "Content-Type" header via the property
> "set.content.type.for.empty.request".
>
> The new implementation should handle DELETE requests with empty body
> correctly or evaluate the existing property
> "set.content.type.for.empty.request".
>
> [1]
> {quote}Although request message framing is independent of the method used,
> content received in a DELETE request has no generally defined semantics,
> cannot alter the meaning or target of the request, and might lead some
> implementations to reject the request and close the connection because of its
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A
> client SHOULD NOT generate content in a DELETE request unless it is made
> directly to an origin server that has previously indicated, in or out of
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing \r\n in multipart request
[
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://XX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID:
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":"X","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://XX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID:
TEST
--uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
{noformat}
... and the webservice
[jira] [Updated] (CXF-8975) Missing \r\n in multipart request
[
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://XX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID:
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":"X","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://XX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID:
TEST
--uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
{noformat}
... and the
[jira] [Created] (CXF-8975) Missing \r\n in multipart request
Guillaume Chauvet created CXF-8975:
--
Summary: 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.5.7, 3.1.4
Reporter: Guillaume Chauvet
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://XX/file
Http-Method: POST
Content-Type: multipart/form-data;
boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
Headers: {Accept=[application/json], Authorization=[Bearer
]}
Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID:
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":"X","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)
