WebdavResource has a pair or methods for each DAV method, like mkcolMethod() and mkcolMethod(path) for MKCOL. mkcolMethod() calls mkcolMethod(path), passing it the path of the url with which that instance of WebdavResource was created. It should pass the encoded/escaped path instead. For example, create the following HttpURL object HttpURL url = new HttpURL("user", "pw, "host", 80, "/$$path$%24"); WebdavResource wd = new WebdavResource( url ); wd.mkColMethod(); mkcolMethod() calls mkcolMethod( httpURL.getPath() ) [=> passing /$$path%24 ] mkcolMethod(path) calls new MkcolMethod( HttpURL.getPath(path) ) [=> passing /$$path$$ ] which results in a request line of MKCOL /%24%24path%24%24 HTTP/1.1 instead of MKCOL /%24%24path%24%2524 HTTP/1.1 I believe that the original mkcolMethod( httpURL.getPath() ); should be mkcolMethod( httpURL.getEscapedPath() ); and that this applies to all these method pairs in WebdavResource. The path passed to the methods of the form method(path) should be an escaped path (this is not clear in the documentation/comments either).
I have a similar problem. I try to make a resource on an url. It does not matter if I use "http://user:pass@devel:9090/webdav/Space Dir" or "http://user:pass@devel:9090/webdav/Space%20Dir" I get the same error: Invalid uri '/webdav/Space Dir': escaped absolute path not valid
The whole thing with correctly escaping URIs has to be reworked in the light of the Commons-Httpclient package. I am currently working on that issue. I propose that all methods take already esacaped URI strings as arguments. That means you have to escape the path yourself before passing it to mkcolMethod(). However if you try this with the current implementation you will run into the problem that the setPath() method of MkcolMethod escapes the path a second time which is wrong (Btw., UnlockMethod exhibits the same problem.)
Just now, I submitted a patch directly to the mailing list which I think addresses this issue. Since my patch addresses a few other unrelated issues, I did not include it as a patch to this bug report. In part this addresses concerns I expressed in an email of 6/18: http://archives.apache.org/eyebrowse/ReadMsg?listName=slide-dev@jakarta.apache.org&msgNo=7205 Hopefully it fixes the issues for others. Feedback welcome.
What is the status of this bug?
As near as I recall, Ingo took my patch and merged it with his, leaving me to think that this issue has been resolved. Certainly the code has been in use by projects at my company for several months now. Hopefully the original reporter will have additional info?
This bug has been fixed. Paths passed to the various methods in WebdavResource are expected to be unescaped, while you have use escaped paths when working with the classes in org.apache.webdav.lib.methods directly.