On Fri, 2015-04-24 at 20:56 +0000, Mark A. Claassen wrote: > Well, I will keep at it. I was hoping there would be clear methodology to > doing this. > Can you explain how the 407, authentication required, would work. In my > current example, I think this would be caught in my determineProxy method and > not require a request to be resubmitted. Or is this what the RetryHandler > was made for? Maybe this is already handled by the default implementation? > > Thanks, >
Mark, why would you want to black-list a proxy based on a 407 response? This does not sound right to me. Anyway, it depends on your specific case to decide what is cheaper: to re-submit the request on I/O error or to preemptively probe proxies. Oleg > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:[email protected] > Voice: (574)232-3784 > Fax: (574)232-4014 > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Friday, April 24, 2015 10:32 AM > To: HttpClient User Discussion > Subject: Re: Proxy Failover > > On Fri, 2015-04-24 at 14:18 +0000, Mark A. Claassen wrote: > > How do I determine the failure type? If the connection can't be > > established, then it can be considered a proxy failure, but there are other > > possible errors that would not involve the proxy. If I just get a > > IOException back, how can I be sure of which type of failure it was? Also, > > is this where I would receive the proxy authentication challenge? If so, > > wouldn't it be better to establish the credentials on a separate connection > > so that the thread making the request can be oblivious to these details? > > > > If you get an I/O error while executing a request via a proxy it is most > likely due to transport to proxy. All other type of errors would be > communicated as HTTP messages. I _guess_ it should be fairly safe to > black-list proxy on any sort of IOException (except for SSL exceptions). > > Oleg > > > Thanks, > > > > Mark Claassen > > Senior Software Engineer > > > > Donnell Systems, Inc. > > 130 South Main Street > > Leighton Plaza Suite 375 > > South Bend, IN 46601 > > E-mail: mailto:[email protected] > > Voice: (574)232-3784 > > Fax: (574)232-4014 > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[email protected]] > > Sent: Friday, April 24, 2015 9:50 AM > > To: HttpClient User Discussion > > Subject: Re: Proxy Failover > > > > On Fri, 2015-04-24 at 13:08 +0000, Mark A. Claassen wrote: > > > Thank you. I did see this, but saw that is was never finished. > > > > > > I looked into the RetryHandler first, but wasn't sure if that was > > > where to put it. It seemed the RetryHandler stuff was not intended > > > to work on non-idempotent operations. That is why I tried to do > > > this in the RoutePlanner, since it would clear that no request > > > entities had yet been sent. (Eventually, I will want to send POST > > > requests through the proxy.) > > > > > > > It will not be very elegant but one probably could have RetryHandler and > > RoutePlanner share state through HttpContext and make RetryHandler > > 'black-list' proxies upon failure instead of RetryHandler probing good > > proxies. > > > > Oleg > > > > > > > Mark Claassen > > > Senior Software Engineer > > > > > > Donnell Systems, Inc. > > > 130 South Main Street > > > Leighton Plaza Suite 375 > > > South Bend, IN 46601 > > > E-mail: mailto:[email protected] > > > Voice: (574)232-3784 > > > Fax: (574)232-4014 > > > > > > > > > -----Original Message----- > > > From: Oleg Kalnichevski [mailto:[email protected]] > > > Sent: Friday, April 24, 2015 6:39 AM > > > To: HttpClient User Discussion > > > Subject: Re: Proxy Failover > > > > > > On Thu, 2015-04-23 at 16:45 +0000, Mark A. Claassen wrote: > > > > I found some information on proxy failover and HttpClient, but not > > > > much. I was wondering, though, if my approach is OK. I realize there > > > > are inefficiencies, but before I go there, I want to know if I am even > > > > on the right track. > > > > > > > > I extended DefautRoutePlanner and implemented the determineProxy method. > > > > In that method I get the list of potential proxies and then test them. > > > > I return the first one in the list that works. (Also, when I find > > > > one that works, I remember it so I don't need to test it again.) > > > > > > > > In my constructor for my route planner, I create a separate HttpClient > > > > instance that just uses the DefaultRoutePlanner, which returns NULL for > > > > determineProxy(). > > > > > > > > Has anyone done anything like this? > > > > > > > > Thanks, > > > > Mark > > > > > > > > > > > > > > > > private boolean testProxy(URI targetURI, Proxy proxy) { > > > > boolean rval; > > > > if (proxy.type() != Proxy.Type.DIRECT) { > > > > InetSocketAddress address = > > > > (InetSocketAddress) proxy.address(); > > > > HttpHost host = new > > > > HttpHost(address.getHostName(), > > > > address.getPort(), ApacheNetworkImpl.SCHEME_HTTP); > > > > > > > > try { > > > > URI uri = new URI(host.toURI()); > > > > RequestBuilder rb = > > > > RequestBuilder.get(uri); > > > > HttpUriRequest request = > > > > rb.build(); > > > > try { > > > > HttpResponse resp = > > > > testClient.execute(request); > > > > rval = true; > > > > } > > > > catch (IOException ex) { > > > > rval = false; > > > > > > > > connectFailed(targetURI, address, ex); > > > > } > > > > finally { > > > > request.abort(); > > > > } > > > > } > > > > catch (URISyntaxException ex) { > > > > rval = false; > > > > } > > > > } > > > > else > > > > rval = true; > > > > return rval; > > > > } > > > > > > > > > > Mark, > > > > > > There is a JIRA for similar feature request > > > > > > https://issues.apache.org/jira/browse/HTTPCLIENT-1176 > > > > > > It should be possible to come with a more efficient solution by using a > > > custom HttpRequestRetryHandler in additional to a custom RoutePlanner. > > > > > > Hope this helps > > > > > > Oleg > > > > > > > > > > > > -------------------------------------------------------------------- > > > - 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] > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
