You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Matti Aarnio (JIRA)" <ji...@apache.org> on 2017/12/21 16:50:00 UTC

[jira] [Created] (HTTPCLIENT-1894) PoolingHttpClientConnectionManager difficulties with client certificate

Matti Aarnio created HTTPCLIENT-1894:
----------------------------------------

             Summary: PoolingHttpClientConnectionManager difficulties with client certificate
                 Key: HTTPCLIENT-1894
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1894
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient (classic)
    Affects Versions: 4.5.4
         Environment: Linux x86-64 Oracle JRE
            Reporter: Matti Aarnio


We run SOAP calls over HTTPS with specific client keypair and certificate attached into communication. We followed tutorial way to create a CloseableHtpClient with customized PoolingHttpClientConnectionManager(), which has a customized Registry<..> instance with appropriately custom constructed SSLSocketFactory instance hooked on our specific client keystore.

However things didn't work as expected. HttpClient kept opening new sockets, and not reusing any.

We created a wrapper class on top of PoolingHttpClientConnectionManager() which logged the received call parameters, and called original function.
Then we saw that {{ConnectionRequest requestConnection(HttpRoute route, Object state)}} was called with {{state = null}}, and that {{void releaseConnection(HttpClientConnection managedConn, Object state, long keepalive, TimeUnit tunit)}} was called with {{state != null}}.

Specifically at release time the state value was HTTPS client certificate Subject in text form, while at request time it was null.

{color:#205081}*So the pool never found any connections returned into pool because lookup criteria did not match the store keys.*{color}

Now that we have a wrapper class on top of {{PoolingHttpClientConnectionManager}} we could simply force the state to be null both on request and on release time, and session reuse works.

We did not use  {{HttpClientContext.setUserToken(Object val)}} before debugging this issue, nor are using any afterwards; during debug we observed that {{requestConnection()}} had our supplied value at {{state}, and {{releaseConnection}} had null. (Opposite to what it did show without UserToken parameter.)

So:  Why does releaseConnection() time supply a state value with TLS client keystore certificate subject value when requestConnection() has state=null, and if I supply requestConnection() with non-null state value, then releaseConnection() has null state value?

There are no pool reuse problems in HTTP URLs, only on HTTPS URLs with client certificate being used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org