Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions

[Simone Bordet]

Hi,

On Mon, Dec 2, 2019 at 7:36 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
>
> Hi,
>
> Could someone please help to verify if the attached patch (JDK 14) works
> HttpComponents?

I'm not sure I see the difference between a generic IOException and
SSLHandshakeException.

If a client is connecting to a busy proxy that sends a TLS
close_notify to the client, that would be a SSLHandshakeException even
though it may be actually possible to retry and get a successful
connection and TLS handshake.
On the other hand, if a busy proxy sends a FIN to the client, that
would be an IOException that may or not succeed when retried.
Or the server is running out of file descriptors, very likely will be
reported as an IOException, but retrying won't help.
Or the client is running out of file descriptors.
Or the client cannot connect to the server (again, a retry may or may
not be successful).

Bottom line is that for both cases (IOException and
SSLHandshakeException) a retry may be successful and as such client
code will have a hard time to detect when or not to retry in either
case.

SSLException (and subclasses) do not report the TLS AlertDescription
code, so it won't be possible to know the exact reason for the
SSLHandshakeException, and from it decide whether it's retryable or
not.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz