You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2007/05/11 18:01:49 UTC
[HttpClient] HttpClient 4.0 progress report (2nd post)
Latest changes in the trunk
===========================
* Ported HTTP request retry handling code from HttpClient 3.x to the new
API.
* Added HttpUriRequest interface extending HttpRequest with additional
support for java.net.URI. Standard HTTP methods retain a reference to an
instance of java.net.URI given at the request construction time that can
be re-used during request execution thus eliminating the need to parse
the request URI multiple times.
* Implemented request wrappers that can be used to revert to the state
of the original request by discarding the auto-generated headers in case
of a redirect or an authentication failure. Request wrappers can also be
used to re-write request URIs if required (for instance when routing
requests via a proxy).
* Changed HttpClient interface to take a single HttpUriRequest parameter
instead of the HttpHost / HttpRequest pair
Roland,
I have a few questions regarding your original code:
(1) What is the difference between a layered and a tunneled HTTP route?
(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.
(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.
Next steps
===========================
* Port redirect handling code
Evil Comrade Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpClient] HttpClient 4.0 progress report (2nd post)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-05-13 at 18:26 +0200, Roland Weber wrote:
> Hi Oleg,
>
> >>> * 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.
>
> Due to time constraints in February, I stopped short of introducing
>
> public interface HttpRoutePlanner {
> HttpRoute routeTo(HttpHost target, HttpContext ctxt); // +params?
> }
>
> That would allow for an implementation similar to the 3.x
> HostConfiguration based one, and an alternative that checks
> the system properties for proxy information. I'm not sure
> how well the parameters fit in. If the request is in the
> context, it's parameters would be available.
>
> Do you think HttpHost objects are suitable for parameters?
> I'd say yes, though we did not explicitly specify a string
> representation that could be used in properties. Conversion
> via URI parsing is straightforward.
> DEFAULT_HOST and DEFAULT_PROXY are reasonable, as parameters
> or context attributes. After all, some people might actually
> be using the relative URI concept in 3.x.
>
Hi Roland
I think any immutable beans are well suited as HTTP parameters. So, I'll
probably go ahead and add these two parameters for now.
Cheers
Oleg
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpClient] HttpClient 4.0 progress report (2nd post)
Posted by Roland Weber <os...@dubioso.net>.
Hi Oleg,
>>> * 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.
Due to time constraints in February, I stopped short of introducing
public interface HttpRoutePlanner {
HttpRoute routeTo(HttpHost target, HttpContext ctxt); // +params?
}
That would allow for an implementation similar to the 3.x
HostConfiguration based one, and an alternative that checks
the system properties for proxy information. I'm not sure
how well the parameters fit in. If the request is in the
context, it's parameters would be available.
Do you think HttpHost objects are suitable for parameters?
I'd say yes, though we did not explicitly specify a string
representation that could be used in properties. Conversion
via URI parsing is straightforward.
DEFAULT_HOST and DEFAULT_PROXY are reasonable, as parameters
or context attributes. After all, some people might actually
be using the relative URI concept in 3.x.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpClient] HttpClient 4.0 progress report (2nd post)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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. $§@%!
>
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpClient] HttpClient 4.0 progress report (2nd post)
Posted by Roland Weber <os...@dubioso.net>.
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. $§@%!
> (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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org