Fabio, Mike has a good point. Allowing the user to have direct access to the underlying HttpConnection bears significant risks, as it may open possibility for all sorts of misuses and abuses.
So, basically you are right. Same HttpConnectionParams would apply to all the connections with the same HostConfiguration. If that poses a problem for you, HttpConnectionParams on a per request method seems the only way out. It's conceptually wrong and ugly, but seems the only possibility to achieve the desired effect without having direct access to the underlying HttpConnection instance. Cheers Oleg -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 11:45 To: Commons HttpClient Project Subject: Re: SoTimeout setting Kalnichevski, Oleg wrote: > I have (what appears to me at) a fairly straight-forward approach: allow > HttpConnectionParams to be created > and customized before physical HttpConnection instance is allocated, when connection > manager > allocates a connection it can look corresponding parameter object up from a hash > map, and, if found, > assign it to the connection. End of the story. With the intent to clarify my previous suggestions: this could be the right approach, for setting a timeout on a per-method base is actually a workaround as Oleg pointed out. A control on the HttpConnecction level would be more suitable. But, if I understand well your intent here and the global httpclient architecture, tieing the customization of HttpConnectionParams to a specific HostConfiguration would prevent different method execution attempts on a host from having different (increasing) timeouts.. Am I missing something? Cheers Fabio --------------------------------------------------------------------- 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]
