On Sat, 2007-05-12 at 18:37 +0200, Roland Weber wrote: > Hi Oleg, > > looks like you fixed quite a few of ye olde problems. > Great job! > > > * Added HttpUriRequest interface extending HttpRequest with additional > > support for java.net.URI. > > > > * Changed HttpClient interface to take a single HttpUriRequest parameter > > instead of the HttpHost / HttpRequest pair > > Thus I assume that the URI needs to be absolute. >
Either it has not be absolute or a default target host needs to be specified in some other way. I was thinking about introducing the DEFAULT_HOST and the DEFAULT_PROXY parameters, which the route building code could fall back onto if the target host has not been explicitly specified in the request URI. > > Roland, > > > > I have a few questions regarding your original code: > > > > (1) What is the difference between a layered and a tunneled HTTP route? > > Tunnelled means a CONNECT has been executed. Layered means > an SSL connection has been established (over the tunnel). > In the old code, these steps were considered atomic. I don't > think that assumption is correct, for example in the presence > of proxy chains or when somebody starts playing tricks by > manually tunnelling through a proxy. > > > (2) Do you envisage custom implementations of the RoutedRequest > > interface? I think it is just a simple tuple of a request and its route > > and it could be made a concrete class, whereas HttpRoute should be an > > interface. Anyone who needs custom details in the RoutedRequest should > > rather provide a custom implementation of the HttpRoute. > > I made that an interface out of a gut feeling. I've come across > too many API classes of which I whished they were interfaces. > The use case I had in mind was a custom HttpRequest that comes > along with it's own route and does have a different base class > so it couldn't be derived from RoutedRequest. I didn't think of > extended route information there. I don't feel strongly about > it. Yes, it's just a tuple, and wouldn't be costly even if an > extra instance had to be created somewhere. > > I guess my own argument above speaks against making HttpRoute > a concrete class. Still, I'd prefer to keep it concrete and > final. It is tightly coupled with RouteTracker, because both > are based on the same concept of a "route". I'm afraid that > almost any custom code would break something here. Both are > final to make sure that their implementations match. > I was thinking of changing HttpRoute and RouteTracker once more > to allow for proxy chains, and then keeping them stable. If any > tricks have to be played when establishing a route, they should > be coded in custom RouteDirector and HttpRequestDirector classes. > That's why all the methods in RouteDirector are non-final. > (an interface for RouteDirector wouldn't have hurt...) > Additional route information could be stored in HttpHost, either > in the scheme name or by extending the class. Which raises the > question of where to put additional tracking information. [EMAIL PROTECTED] > I have not looked very closely at your route tracking code, so I cannot really help at the moment. Let's keep it on the back burner until BETA1 > > (3) Would you object removing #getConnectionManager() from HttpClient > > interface? I suspect rather strongly ClientConnectionManager interface > > in its present form cannot be used to manage NIO based connections. This > > also causes HttpClient interface to be unusable for non-blocking > > implementations. > > If you see a chance of using the HttpClient interface with NIO, > drop getConnectionManager(). Having it in the implementation class > or an extended interface is sufficient. > My scepticism about benefits of using NIO for pure HTTP clients is well known. Nonetheless I would like to keep this an option. Cheers Oleg > cheers, > Roland > > > --------------------------------------------------------------------- > 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]
