On Thu, 2019-06-13 at 11:57 -0700, Ryan Schmitt wrote: > > Therefore the HttpClient's default retry implementation does no > > longer > > retry Connection Resets happening while reading on an established > connection, because all SSLException are excluded from retries. > > I'm trying to understand exactly which failure mode is affected by > the > underlying change. I think you're describing the case where a > connection > reset occurs while the SSL handshake is being performed over an > established > TCP connection, and the desired retry behavior is to reconnect (over > a new > TCP connection) and negotiate TLS from scratch. Is this correct? > > On Thu, Jun 13, 2019 at 9:26 AM Eric Hubert < > [email protected]> > wrote: > > > Hi! > > > > Since using OpenJDK 11 I noticed a behavioral change in the default > > retry > > handling of HttpClient for https URLs caused by an implementation > > change in > > the JDK. > > AFAIK until including OpenJDK 10 Java was throwing SocketException > > directly for both Socket and SSLSocket implementatons when they > > occurred. > > With OpenJDK 11 now Java wraps those in SSLExceptions. Prior > > OpenJDK > > 11.0.3 the subclass SSLProtocolException was (mistakenly) used, > > resulting > > in the following bug report: > > https://bugs.openjdk.java.net/browse/JDK-8214339 > > > > After the fix with OpenJDK 11.0.3 / OpenJDK 12.0.1 it is still the > > base > > class SSLException. Therefore the HttpClient's default retry > > implementation > > does no longer retry Connection Resets happening while reading on > > an > > established connection, because all SSLException are excluded from > > retries. > >
Hi Eric SSLException classes do not trigger automatic request re-execution because it is pointless to retry the request execution in case of a SSL handshake / protocol / key material / unverified peer error. The new TLSv1.3 implementation in Java 11 has been causing quite a bit of grief by behaving subtly different than older protocol implementations. I am open to excluding more specific SSL exception classes such as SSLProtocolException, SSLKeyException, SSLHandshakeException and SSLPeerUnverifiedException instead of their base class but preferably in HC 5.0, not in HC 4.x. ... > > > > Now the question: What do others think - should the default > > implementation > > be adjusted to also provide a behavior for OpenJDK >= 11 similar to > > those > > of previous versions? > > How could such a change look like? We now check the cause of > > SSLException. > > > > Additionally I have another question in the context of retry > > handling. > > Wouldn't it be more flexible, if the retry logging will be moved > > from > > org.apache.http.impl.execchain.RetryExec#execute to the actual > > RetryHandler > > implementation? The INFO logging in RetryExec is already too much > > for some > > users (they will likely set the level of the logger to WARN) but > > containing > > too less context information for others. If the logging would be in > > the > > RetryHandler implementation itself, custom implementations/sub > > classes > > could adjust it to the specific requirements. What do others say? > > Maybe I'm > > missing something here. > > Please feel free to propose a patch by raising a PR at GitHub. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
