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