On Tue, 26 Jan 2021 18:56:57 GMT, Clive Verghese <cvergh...@openjdk.org> wrote:
>> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears
>> to not be fully fixed
>>
>> This also fixes JDK-8259516: Alerts sent by peer may not be received
>> correctly during TLS handshake
>
> Clive Verghese has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains four commits:
>
> - Update copyright year
> - Add error handling guidelines
> - Fix bugids and use server port passed as a parameter
> - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1425:
> 1423: } catch (SocketException se) {
> 1424: // don't change exception in case of SocketException
> 1425: throw se;
I may add the SocketException catch line together within line 1420.
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1491:
> 1489: } catch (SocketException se) {
> 1490: // don't change exception in case of SocketException
> 1491: throw se;
I may add the SocketException catch line together within line 1489.
src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1702:
> 1700: if (!conContext.isInboundClosed()) {
> 1701: try {
> 1702: decode(null);
One decode may be not sufficient if there are multiple pending handshake
messages record, or the connection has been established and application data
transportation is in progress. I'm not sure if an additional decode() here
really solve the problem as described in JDK-8259516.
I did not follow the issue of JDK-8259516. Why an SSLException is desired but
not SocketException, as if the socket has been closed?
src/java.base/share/classes/sun/security/ssl/SSLTransport.java line 146:
> 144: } catch (SocketException se) {
> 145: // don't change exception in case of SocketException
> 146: throw se;
I may add the SocketException catch line together within line 141.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2057
