hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wilcox, Mark" <Mark.Wil...@webct.com>
Subject RE: [PATCH] Why is the HttpConnectionManager a field in HttpState?
Date Thu, 08 May 2003 22:09:40 GMT
Being late to the thread, this might already have been mentioned, but I wonder if you couldn't
just pass in an InputStream/OutputStream that was already opened to the proxy SSL server?
Then have HTTPClient read/write to those streams? This way you'd also have a handy way to
log messages for debugging or whatever (if you stacked streams).
 
Socket s = Socket(some parameters);
s.bind(some port);
HttpClient.setInputStream(s.getInputStream());
HttpClient.setOutputStream(s.getOutputStream());
 
And it would seem to me that you'd be able to do multiple ops this way as well.
 
But then you'd could also say use a proxy server like stunnel or Proxyimitron which lets you
speak on localhost:port and handles the redirects for you.
 
But I could also be way off base :)
 
Mark 

	-----Original Message----- 
	From: Michael Becke [mailto:becke@u.washington.edu] 
	Sent: Thu 5/8/2003 5:55 PM 
	To: Commons HttpClient Project 
	Cc: 
	Subject: Re: [PATCH] Why is the HttpConnectionManager a field in HttpState?
	
	

	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
	>
	
	
	---------------------------------------------------------------------
	To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
	For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
	
	

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message