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. > 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] > (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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
