>> I guess someone really has to bring the server part up to date and merge the org.apache.util packages into one.
You mean that the HttpClient packages need to be merged?? Why, are they that different to each other? Or is it just that the server needs to be compiled against the same version of HttpClient as the client uses? Warwick ----------------------------------------------------------- Warwick Burrows E2open Senior Engineer 9600 Great Hills Trail, #325 http://www.e2open.com Austin TX 78759 ----------------------------------------------------------- -----Original Message----- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 4:27 AM To: [EMAIL PROTECTED] Subject: Re: Problem with setWebdavProperties method The URI class from Httpclient is correct. Slide, which is still using a very old variant of Httpclient for the server part, incorrectly escapes those characters. One of the developers noted this inconsistency between client and server versions not long ago. I guess someone really has to bring the server part up to date and merge the org.apache.util packages into one. Ingo > Hi, > > I have a problem with Slide 2.1 M1 where I can create and delete a > folder called "$$" using the slide dav client but then can't put or cd > into it. I can even create subfolders under the $$ folder with the > command line client > - just not cd or put into it. I can also access my $$ folder and its > subfolders from a web browser as the urls have been escaped correctly by the > slide server. The problem occurs because of a comparison made between the > escaped URL and the href element returned in the response body of a PROPFIND > method that's made while setting the new path in the WebdavResource with the > setPath() method. The href returned by the server is the URL path with an > escaped (and I would think correct) version of the string "$$" eg. > "/slide/files/%24%24" -- whereas the call to the HttpUrl.getEscapedPath() > made in setWebdavProperties() returns a path with "/slide/files/$$" in it. > > I tracked the problem back to where the target URI is first encoded by > the > HttpClient.URI.setPath() method which doesn't escape the $ characters > because $ is considered one of the legal chars for the 'allowed_abs_path' > character set. Is this a bug in the HttpClient.URI implementation? > Shouldn't the "$" and ":" character be escaped like the (space) character > is? > > Thanks, > Warwick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
