RFR: 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader

[zhurs]

On Thu, 25 May 2023 21:40:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
>> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.
>
> Hi, thanks a lot for the bug report and the fix.
> 
> The fix looks reasonable, however the test fails quite consistently in our CI on many platform:
> 
> 
> java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes
> 	at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ?

@dfuch, thanks for your lightning-fast reply.

Indeed it relies on buffer sizes.
The test works for me on Linux and Mac, but real life seems to be more diverse.

Unfortunately, I don't know how else to reproduce the problem and test the fix - the tested logic is hidden deep.

It may be possible to commit the fix without unit-test?
The regression is not affected, and the behavior can be checked manually using the recipe from the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563562380