[jira] [Commented] (CXF-8946) HttpClient in CXF causing memory leak
[
https://issues.apache.org/jira/browse/CXF-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813789#comment-17813789
]
John Yin commented on CXF-8946:
---
I am getting OutOfMemoryException with CXF 3.6.2 and OpenJ9 (IBM Semeru
ibm-semeru-open-jre_x64_windows_17.0.9_9_openj9-0.41.0). In the dump, there
are two thousands of threads "HttpClient--SelectorManager". Not sure
whether it is related to this issue or
https://issues.apache.org/jira/browse/CXF-8885. I do not see this issue if
using Hotspot JVM. If it is not related to this issue, I will open a new one.
Thanks!
> HttpClient in CXF causing memory leak
> -
>
> Key: CXF-8946
> URL: https://issues.apache.org/jira/browse/CXF-8946
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
> Attachments: CXF-HTTPClient-MemoryLeak.zip, Screenshot 2023-10-19 at
> 2.29.56 PM.png, call_mem_leak.sh, java_pid17394.hprof.zip,
> java_pid17394_Leak_Suspects.zip, java_pid91652.0001.hprof.zip,
> java_pid91652.0001_Leak_Suspects.zip, memory-leak-demo.zip, screenshot-1.png,
> screenshot-2.png
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is a memory leak.
> We found this when running it in spring boot using
> {code:java}
> @Async{code}
>
> I have tried to reproduce it using the attached code, and it seems to work
> with a low heap size.
>
> You can execute the code like so:
> {code:java}
> mvn compile exec:exec{code}
--
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)
