Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Sat, 23 May 2015 14:11:17 +0000 (UTC)
From: "Alexandre (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12832263.1432327072000.16897.1432390277386@Atlassian.JIRA>
In-Reply-To: <JIRA.12832263.1432327072000@Atlassian.JIRA>
References: <JIRA.12832263.1432327072000@Atlassian.JIRA>
 <JIRA.12832263.1432327072022@arcas>
Subject: [jira] [Updated] (HTTPCLIENT-1650) Fluent Executor doesn't inherit
 auth scheme and creds provider of HttpClient instance
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Alexandre updated HTTPCLIENT-1650:
----------------------------------
    Description: 
When instantiating an Executor from an existing HttpClient instance, the Executor doesn't inherit the credentials provider.

Executor(final HttpClient httpclient) {
        super();
        this.httpclient = httpclient;
        this.credentialsProvider = new BasicCredentialsProvider();
        this.authCache = new BasicAuthCache();
 }

For instance, to perform an HTTP request using the Windows integrated authentication, the following will correctly authenticate:

WinHttpClients.createDefault().execute(new HttpGet(...));

But this will not:

Executor.newInstance(defaultWinHttpClient).execute(Request.Get(...))

I think that this behavior is very counter-intuitive and limiting at the same time. When an Executor is instantiated from an HttpClient instance, all configurations from that instance should be taken in account.


  was:
When instantiating an Executor from an existing HttpClient instance, the Executor doesn't inherit the registry of authentication schemes and the credentials provider.

For instance, to perform an HTTP request using the Windows integrated authentication, the following will correctly authenticate:

WinHttpClients.createDefault().execute(new HttpGet(...));

But this will not:

Executor.newInstance(defaultWinHttpClient).execute(Request.Get(...))

I think that this behavior is very counter-intuitive and limiting at the same time. When an Executor is instantiated from an HttpClient instance, all configurations from that instance should be taken in account.


> Fluent Executor doesn't inherit auth scheme and creds provider of HttpClient instance
> -------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1650
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1650
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: Fluent HC
>    Affects Versions: 4.4.1
>         Environment: Windows Server 2008
>            Reporter: Alexandre
>              Labels: flexibility
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When instantiating an Executor from an existing HttpClient instance, the Executor doesn't inherit the credentials provider.
> Executor(final HttpClient httpclient) {
>         super();
>         this.httpclient = httpclient;
>         this.credentialsProvider = new BasicCredentialsProvider();
>         this.authCache = new BasicAuthCache();
>  }
> For instance, to perform an HTTP request using the Windows integrated authentication, the following will correctly authenticate:
> WinHttpClients.createDefault().execute(new HttpGet(...));
> But this will not:
> Executor.newInstance(defaultWinHttpClient).execute(Request.Get(...))
> I think that this behavior is very counter-intuitive and limiting at the same time. When an Executor is instantiated from an HttpClient instance, all configurations from that instance should be taken in account.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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