hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: [PATCH] Why is the HttpConnectionManager a field in HttpState?
Date Thu, 08 May 2003 21:55:11 GMT
Initially I was leaning towards the first solution, but I have just 
discovered something that may make it not generally feasible.  I 
thought Socket night accept a -1 for local port, but alas no.  If we 
were to specify a local host/port, only one connection could be open 
per host config.

As Oleg said, it might be better to make a more obscure solution.  Any 
suggestions on how to fix the case for tunneled HTTPS connections?

Mike

On Thursday, May 8, 2003, at 03:12 PM, Oleg Kalnichevski wrote:

> Laura
>
> - The first approach would be more generic and in many ways proper. My
> only concern is that HttpConnection class is really getting overloaded
> with too many options
>
> - The second one would be far easier to implement. I see no problem to
> apply a few tweaks to HttpConnection#open() to make this option 
> feasible
>
> The most important decision factor (imho) is how relevant is the 
> ability
> to set local address for the greatest majority of the HttpClient user
> base. If there may be a significant demand for it, we should go for the
> first option. If it is likely to be a fairly obscure and rarely used
> feature, I (personally) would rather prefer the second option.
>
> Cheers
>
> Oleg
>
>
>
> On Wed, 2003-05-07 at 20:30, Laura Werner wrote:
>> Kalnichevski, Oleg wrote:
>>
>>> Do you foresee any further API change requests that you might need 
>>> to go through before the 2.0 release?
>>>
>> I've got one more patch I'm working on, but I'll go ahead and float 
>> the
>> idea here to see if people think it's a good idea at all.
>>
>> On clustered or multi-homed systems, there's a need to specify the 
>> local
>> bind address of sockets, so you can make sure they're on the right
>> interface.  The way we did this in our old, patched version of
>> httpclient was to add a "setInterface(InetAddress)" method to
>> HttpConnection.  Since we were using HttpConnection directly, this was
>> all it took.
>>
>> I can think of a couple of ways to do this in the new release:
>> - Add similar methods.  I think I'd add a 
>> "setLocalAddress(InetAddress)"
>> method to both HttpConnection and HttpConnectionManager.  (or maybe 
>> just
>> MultiThreadedHttpConnectionManager).
>>
>> - Stash the "local address" info in the HostConfiguration via
>> set/getLocalAddress methods
>>
>> - It might also be possible to do it without API changes.  If I create
>> my own "Protocol" objects and give them custom ProtocolSocketFactory
>> objects that do the local address magic, that would handle most of
>> this.  The one exception is the  spot in HttpConnection.open() where 
>> it
>> does an explicit "new DefaultProtocolSocketFactory()" for secure 
>> proxied
>> connections.  I'm not sure how to override that one without an API 
>> change.
>>
>> I'd love to hear comments on these ideas.
>>
>> -- Laura
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: 
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>


Mime
View raw message