Webdav client expectations mismatch

[Eric Johnson <er...@tibco.com>]

At least there seems to be a mismatch in expectations between what 
HttpClient does with URIs, and what slide-webdavlib currently expects.

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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org