HttpMethodBase constructor takes String as an argument, and it is allowed to be either an absolute URL, or a relative URL. If it is server-relative URL, then the host configuration must be set on HttpClient. Otherwise, HttpClient now keeps "state" information such that a single HttpClient object can be used for multiple servers simultaneously. Why does any of this matter? It would seem that the extensions to HttpClient for WebDAV only allow the "server-relative" references, not the absolute references.
If you pass "http://myserver:8080/foo"; to PropFindMethod, OptionsMethod, DeleteMethod, LockMethod, ...., HttpRequestBodyMethodBase calls URIUtil.URLEncode(), except that that request has the effect of encoding the two colons that appear in the URL, and the request subsequently fails. My suggestion is to change these methods to assume that the URL passed to the constructor or setPath() is _already_ encoded as a URL. To do otherwise is to continual fight the underlying expectations of HttpClient, and break clients expectations when switching back and forth between the two APIs. This is especially true now that the HttpClient methods can take full paths in their constructors, but slide-webdavclient cannot due to the above encoding issue.
Any objections to a patch along those lines? While I'm at it, I'm going to clean up the uses of now deprecated functionality in HttpClient, and fix up the javadoc for JDK 1.4 compiles.
-Eric Johnson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
