RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278
Alan.Bateman at oracle.com
Thu Feb 15 08:15:16 UTC 2018
On 15/02/2018 07:49, Xueming Shen wrote:
> Please help review the change for JDK-819798
> issue: https://bugs.openjdk.java.net/browse/JDK-8197988
> webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev
> The change for JDK-8164278 caused a decoding regression. A Tier2
> test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that
> uses mime-base64-decoder failed.
> The "condition" that triggers the decoding to go the fast path is
> incorrect in
> the code pushed for JDK-819798.
> The intent here is to only start/try the fast path when we are at the
> of a 4-byte legal base64 unit. The correct/appropriate check is to see if
> shiftto == 18, which means the decoder is still at the beginning of
> unit. ( bits == 0 is a false indicator, as bits might include decoded
> byte value of
> 0). The fix is a relatively easy/one line change.
This looks okay. Should we create another issue to add more tests in
this area to avoid the SSL code finding issues in this area again.
More information about the core-libs-dev