[jira] [Updated] (CXF-4645) AsyncHTTPConduit does not re-use NTLM authenticated connections

["Daniel Kulp (JIRA)" <ji...@apache.org>]

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

Daniel Kulp updated CXF-4645:
-----------------------------

    Description: 
I´ve started using AsyncHTTPConduit with NTLM, and have seen that connections are never re-used over consecutive requests.

I have debugged the entire stack, and found that the pooling mechanism in apache http client async is using the "http.user-token" (ClientContext.USER_TOKEN) property to find existing connections for re-use.

I managed to patch the AsyncHTTPConduit (from 2.7.0 tag) so that it actually does re-use connections with NTLM. However, I´m not very familiar with the cfx code base and do not know the side-effects of this change.

{code:java}
protected void connect(boolean output) throws IOException {
...
if (tlsClientParameters != null && tlsClientParameters.hashCode() == lastTlsHash && sslState != null) {
                ctx.setAttribute(ClientContext.USER_TOKEN , sslState);
            } else if (client.getCredentialsProvider().getCredentials(AuthScope.ANY) != null) {
                ctx.setAttribute(ClientContext.USER_TOKEN, client.getCredentialsProvider()
                    .getCredentials(AuthScope.ANY).getUserPrincipal());
            }
...
{code}

  was:
I´ve started using AsyncHTTPConduit with NTLM, and have seen that connections are never re-used over consecutive requests.

I have debugged the entire stack, and found that the pooling mechanism in apache http client async is using the "http.user-token" (ClientContext.USER_TOKEN) property to find existing connections for re-use.

I managed to patch the AsyncHTTPConduit (from 2.7.0 tag) so that it actually does re-use connections with NTLM. However, I´m not very familiar with the cfx code base and do not know the side-effects of this change.

protected void connect(boolean output) throws IOException {
...
if (tlsClientParameters != null && tlsClientParameters.hashCode() == lastTlsHash && sslState != null) {
                ctx.setAttribute(ClientContext.USER_TOKEN , sslState);
            } else if (client.getCredentialsProvider().getCredentials(AuthScope.ANY) != null) {
                ctx.setAttribute(ClientContext.USER_TOKEN, client.getCredentialsProvider()
                    .getCredentials(AuthScope.ANY).getUserPrincipal());
            }
...


    
> AsyncHTTPConduit does not re-use NTLM authenticated connections
> ---------------------------------------------------------------
>
>                 Key: CXF-4645
>                 URL: https://issues.apache.org/jira/browse/CXF-4645
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.7.0
>            Reporter: Øystein Grimstad
>
> I´ve started using AsyncHTTPConduit with NTLM, and have seen that connections are never re-used over consecutive requests.
> I have debugged the entire stack, and found that the pooling mechanism in apache http client async is using the "http.user-token" (ClientContext.USER_TOKEN) property to find existing connections for re-use.
> I managed to patch the AsyncHTTPConduit (from 2.7.0 tag) so that it actually does re-use connections with NTLM. However, I´m not very familiar with the cfx code base and do not know the side-effects of this change.
> {code:java}
> protected void connect(boolean output) throws IOException {
> ...
> if (tlsClientParameters != null && tlsClientParameters.hashCode() == lastTlsHash && sslState != null) {
>                 ctx.setAttribute(ClientContext.USER_TOKEN , sslState);
>             } else if (client.getCredentialsProvider().getCredentials(AuthScope.ANY) != null) {
>                 ctx.setAttribute(ClientContext.USER_TOKEN, client.getCredentialsProvider()
>                     .getCredentials(AuthScope.ANY).getUserPrincipal());
>             }
> ...
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira