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

["Oleg Kalnichevski (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-1894.
-------------------------------------------
    Resolution: Invalid

bq. 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?

Do requests share the same execution context? If not HttpClient cannot be sure they are logically related and executed with the same security context / user identity.

For details see
http://hc.apache.org/httpcomponents-client-4.5.x/tutorial/html/advanced.html#stateful_conn

Oleg

> 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 {{CloseableHttpClient}} 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