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