Thank You for the quick response. Can we get a confirmation that this issue is resolved in later versions or a probable solution can be designed for the described scenario? The reason we ask is our product bundled v4.2.5(upgraded from 3.1) of the library in April 2013 and moving to 4.3/4.4 would mean a lot of API/design changes that can significantly impact the product stability. It is therefore desirable for us to move to a stable version which is covered under under Long Term Suppor (LTS). Is there a plan to support 4.3/4.4 for longer term or can you let us know the current outlook for ending support for those streams? Also we will be interested to know if any support will be provided on 4.2 stream on buying support for annual fee.
Thank you hoping for a quick response. On Mon, Dec 15, 2014 at 7:48 PM, Oleg Kalnichevski <[email protected]> wrote: > > On Mon, 2014-12-15 at 17:46 +0530, srihari na wrote: > > Hello Folks, > > > > We are using HttpClient 4.2.5 and Our scenario is that there is only 1 > > instance of HTTP client throughout the JVM and only one connection pool > > linked to client. The same client using the single connection pool > > interacts with various http/https endpoints by creating a new method > > instance for every request. For https based connections we have our own > > implementation for socket connection factory, when we try to register a > new > > custom scheme using custom socket factory via local context, it is not > > being picked by the client. It always tries to get the list of scheme > > registries from connection manager even though we try to override at > local > > context level. We use local context to pass authentication information > > which works perfectly fine however schemeregistry is not picked up. > > > > AbstractHttpClient > > protected HttpRoutePlanner createHttpRoutePlanner() { > > return new DefaultHttpRoutePlanner(*getConnectionManager* > > *().getSchemeRegistry()*); > > } > > > > > > Now that local context scheme registry is not picked up we tried > > registering all the schemes at connection manager level with unique > scheme > > names and pass the respective scheme name in the HttpHost of the execute > > method. > > In the first pass route planner has the proper scheme name we set in the > > HttpHost so it pickedup the proper socket factory > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest, > HttpContext) > > line: 113 > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest, HttpContext) > > line: 791 > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext) line: > 414 > > DefaultHttpClient(AbstractHttpClient).execute(HttpHost, HttpRequest, > > HttpContext) line: 906 > > > > In the second pass the target it reconstructed using the URI so the > custom > > scheme name is lost and our custom socket factory is not picked up > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse, > > HttpContext) line: 1110 > > *HttpHost newTarget = URIUtils.extractHost(uri);* > > > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest, > HttpContext) > > line: 113 > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest, HttpContext) > > line: 791 > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse, > > HttpContext) line: 1129 > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext) line: > 548 > > > > Request the forum to help solve our scenario. You help is much > appreciated, > > awaiting a quick response. > > > > Thank you > > > > Please consider upgrading to 4.3.x. Even if it is a bug in HttpClient > there will be no more releases from the 4.2.x branch. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Srihari NA
