Hi,
Finally I found a solution.
I create a new SchemeRegistry on each request thread that need
specific trust and key material and I add it as a SCHEME_REGISTRY
attribute to a Context variable(each thread maintains its own
dedicated instance of HttpContext). Then I use the singleton
httpClient and that new context to execute the request. Using this I
can use a custom SchemeRegistry for each request with a singleton
httpclient bean.
BUT I found that SCHEME_REGISTRY context attribute is not working
properly in httpclient execute method (httpClient.execute(httpPost,
context);) I dig into httpclient code to discover that this attribute
is not readed. I isolate the problem to a single class,
org.apache.http.impl.conn.DefaultClientConnectionOperator. The method
openConnection gets default schemeRegistry instead of look first at
context, so I write some code to fix this and it works great now.
BEFORE:
public void openConnection(
final OperatedClientConnection conn,
final HttpHost target,
final InetAddress local,
final HttpContext context,
final HttpParams params) throws IOException {
if (conn == null) {
throw new IllegalArgumentException("Connection may not be null");
}
if (target == null) {
throw new IllegalArgumentException("Target host may not be null");
}
if (params == null) {
throw new IllegalArgumentException("Parameters may not be null");
}
if (conn.isOpen()) {
throw new IllegalStateException("Connection must not be open");
}
Scheme schm = schemeRegistry.getScheme(target.getSchemeName());
SchemeSocketFactory sf = schm.getSchemeSocketFactory();
.
.
.
AFTER:
public void openConnection(
final OperatedClientConnection conn,
final HttpHost target,
final InetAddress local,
final HttpContext context,
final HttpParams params) throws IOException {
if (conn == null) {
throw new IllegalArgumentException("Connection may not be null");
}
if (target == null) {
throw new IllegalArgumentException("Target host may not be null");
}
if (params == null) {
throw new IllegalArgumentException("Parameters may not be null");
}
if (conn.isOpen()) {
throw new IllegalStateException("Connection must not be open");
}
//Changes here!
Scheme schm;
if ((context != null) &&
(context.getAttribute(ClientContext.SCHEME_REGISTRY) != null)) {
schm =
((SchemeRegistry)context.getAttribute(ClientContext.SCHEME_REGISTRY)).getScheme(target.getSchemeName());
}
else {
schm = schemeRegistry.getScheme(target.getSchemeName());
}
SchemeSocketFactory sf = schm.getSchemeSocketFactory();
.
.
.
I can send a patch if you find it correct, for me it works.
2012/5/29 Oleg Kalnichevski <[email protected]>:
> On Tue, 2012-05-29 at 16:17 +0200, Jose Escobar wrote:
>> Hi there,
>>
>> First of all let me say English is not my native language; please
>> excuse typing errors.
>>
>> I'm using Httpclient 4.2 on a Spring project to send Http Post
>> requests. It's working correctly with a singleton DefaultHttpClient
>> bean managed by a PoolingClientConnectionManager. This
>> PoolingClientConnectionManager has two schemas, http default port 80
>> and https default port 443 with default jsse trust certificates and a
>> key to authenticate the client to remote servers. As I say it works
>> great but now I have to validate some remote servers with given
>> certificates and they are not signed by default jsse trust
>> certificates. I don't want to simply add this new certificates to the
>> trusted certificates keystore because I only want to use them against
>> specific Urls for security reasons (I don't know how are they managing
>> their private keys).
>>
>> Is it possible to add these certificates to a singleton httpclient and
>> remove them after execute a HttpPost without affect others parallel
>> working threads that are using the same httpClient or may I should
>> create a new HttpClient instance with the apropiate trust
>> certificates?
>>
>>
>
> Possibly a better option might be a custom socket factory that can
> create SSL connections with different SSL contexts using different trust
> and key material based on the hostname of the target server.
>
> Hope this helps
>
> Oleg
>
>>
>> I can send some code if you needed. Sorry for my english again...
>>
>> Thanks in advance.
>>
>> Jose E.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
