[
https://issues.apache.org/jira/browse/HTTPCORE-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18090406#comment-18090406
]
ASF subversion and git services commented on HTTPCORE-775:
----------------------------------------------------------
Commit d21261e42651a531b8c4f009ded7bb8c478de5c1 in httpcomponents-core's branch
refs/heads/master from Ryan Schmitt
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=d21261e42 ]
SSLIOSession: Fix regression in backpressure handling
A regression was introduced by PR #513, submitted as a fix for
HTTPCORE-775, which claimed that `SSLIOSession::write` was failing to
"handle" `SSLEngineResult#BUFFER_OVERFLOW`. The issue was encountered by
Apache CXF, who provided a test case demonstrating the problem:
https://github.com/apache/cxf/pull/2214/changes
I investigated this reproducer and found that CXF was actually hanging
due to not signaling the availability of more data:
https://github.com/apache/cxf/blob/f1b2c37bd9f3606cf7ca2d5d39cc1168e94fd9e4/rt/transports/http-hc5/src/main/java/org/apache/cxf/transport/http/asyncclient/hc5/CXFHttpAsyncRequestProducer.java#L97
when `SSLIOSession#write` signaled backpressure here:
https://github.com/apache/cxf/blob/f1b2c37bd9f3606cf7ca2d5d39cc1168e94fd9e4/rt/transports/http-hc5/src/main/java/org/apache/cxf/transport/http/asyncclient/hc5/CXFHttpAsyncRequestProducer.java#L75
The return value of `buf.produceContent` (which is ultimately
`SSLEngineResult#bytesConsumed` -- 0, in this case) is simply being
discarded. Changing the `CXFHttpAsyncRequestProducer#available` method
as follows causes the problematic test cases to succeed instantly:
```
@Override
public int available() {
if (buffer != null && buffer.hasRemaining()) {
return buffer.remaining();
} else if (buf != null && buf.length() > 0) {
return buf.length();
}
return 0;
}
```
Additionally, that PR appears to have introduced dysfunctional
backpressure handling into `SSLIOSession` by simply expanding the buffer
as much as necessary to hold the encrypted `src` buffer. This in turn
has caused a significant regression in heap usage and latency, hence the
need to revert. I've retained the test changes, since they did introduce
more coverage for TLSv1.3.
> The SSLIOSession::write does not handle SSLEngineResult#BUFFER_OVERFLOW
> -----------------------------------------------------------------------
>
> Key: HTTPCORE-775
> URL: https://issues.apache.org/jira/browse/HTTPCORE-775
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.3.1
> Reporter: Andriy Redko
> Priority: Major
> Fix For: 5.3.3, 5.4-alpha1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In Apache CXF, we have received an issue from the user
> (https://issues.apache.org/jira/browse/CXF-9093) that HTTP client (backed by
> Apache HttpClient 5.4.1 / Apache HttpCore 5.3.1) basically hangs with
> payloads > 2.5kb and TLSv1.3.
> It turned out that the problem is SSLIOSession::write method (more
> specifically,
> https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/reactor/ssl/SSLIOSession.java#L672)
> that does not handle SSLEngineResult#BUFFER_OVERFLOW, causing the processing
> loop to stuck. In this case, the buffer is limited by getPacketSize()
> (~16Kb). There is a mitigation (pass
> -Djsse.SSLEngine.acceptLargeFragments=true) but it is also limited to a bit
> larger requests.
> We have crafted a CXF specific test cases which reproduce the issue very
> reliably (https://github.com/apache/cxf/pull/2214). I am happy to work on the
> fix (if the issue makes sense) or provide minimal reproducer (if the team is
> interested to pick it up).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
