Pill, Juergen wrote:
Hello,
We want to suggest a sematical interface change within the WebDAV method implementation of the client API (org.apache.webdav.lib.methods.xxxMethod).
Currently some of those methods do url-encoding (with utf-8) some do not. The basis of those classes is the HttpClient which expects all URLs already encoded, e.g. does no extra URL encoding.
We suggest implementing the same behavior (no extra URL encoding) in the WebDAV API layer too.
Reasons:
* consistency - if all the existing methods expect already encoded paths, then users will expect it to work this way. * preventing stupid bugs by users - imagine a case where a library user does a HeadMethod request (already encoded), and then discovers to their suprise that they cannot pass the exact same URL to PropFindMethod, but must _decode_ the URL before passing it. * import confusion - if you import the "GetMethod" from webdavclient, rather than from httpclient, it is impossible to tell except by looking back at your import statement whether the URL should be encoded or not. I've tripped over this one. * full URLs vs. partial paths - With the 2.0 release of HttpClient, it is possible to pass either a full URLto a XxxMethod constructor, or to set the HostConfiguration on HttpClient and pass a server relative path to the XxxxMethod constructor. I originally tripped over a problem because I was passing full URLs to the PropFindMethod(), only to discover that "http://localhost:8080/"; was getting converted to "http%3A//localhost%3A8080/" and then failing.
Please vote:
Modify the WebDAV client API in a way that no additional encoding is taking place. The calling layer will (need to) do the necessary encoding. [ ] +1. I agree with the change. [ ] +0. I don't care. [ ] -1. I don't agree, because:
Best regards,
Juergen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
