I compiled against the very latest CVS code at the time - it was early last week when I did my last CVS update.
I also ran into the IllegalArgumentException as well as a few others. I made the modifications I described below which only got me to the next exception. Since my compelling reason for going to the new code was to get the updated Interceptor API, I found it easier to just back-port the newer version of the API into the working 1.0.16 code base. If anyone is interested in the patches to upgrade 1.0.16 to the same Interceptor API as appears in the 2.0.0 release, please let me know and I'll post it. In particular I needed to know when documents had been removed so I could keep a lucene search index in sync with the documents. This was the key missing part of the 1.0.16 Interceptor API. Brian -----Original Message----- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 2:18 AM To: [EMAIL PROTECTED] Subject: Re: URL Encoding happening too often... Hi Brian, are you using the latest cvs code? My attempt to try this out, revealed another problem. Commons-httpclient was changed not long ago to take already escaped paths in the HttpMethodBase constructor. But Slide does not do the encoding at this point. So I get an IllegalArgumentException on a call to a method from within WebdavResource if the path contains spaces. Regards, Ingo > I have a client tool I've developed against slide 1.0.16 which has been > working well for quite a while now. I needed to integrate Lucene based > search into my project and found that slide 2.0.0 (cvs head) had an > Interceptor API which I could easily leverage for my needs. Here's the > problem: > > =20 > > I am having trouble with the 2.0.0 release in that any files which = > result in > a different URI when URLEncoded result in 404 errors from the slide = > server. > I can perform uploads (PUT) without any issues, but when I do a PROPFIND = > for > example, a 404 results. The problem seems to be in the > commons-httpclient.jar provided with slide in the cvs tree. Using the > TcpTunnelGui provided in the apache soap project, I am able to monitor = > the > traffic between my client (using commons-httpclient.jar) and the slide > server to isolate the problem. In case anyone isn't familiar with this = > tool, > it's very handy and I suggest you check it out. > > =20 > > C:\devapps\soap-2_3_1\lib>java -cp soap.jar > org.apache.soap.util.net.TcpTunnelGui 8081 localhost 8080 > > =20 > > What seems to be happening is that the commons-httpclient.jar is = > performing > the URL encoding twice for some, but not all methods. The sample file I = > am > using has a space in the filename. "Junk File.txt". It appears correctly = > in > the property store and object tables after an upload completes, but when = > I > do a webdavResource.propfindMethod(.) it fails. The request generated by > httpclient converts the filename into "Junk%2520File.txt" instead of the > proper "Junk%20File.txt". Here's how that's happening: > > =20 > > "Junk File.txt" --> (encoded once) "Junk%20File.txt" --> (encoded again) > "Junk%2520File.txt" > > =20 > > I have tracked down where these encoding operations are happening and = > would > appreciate some guidance from any of those of you more versed in the = > APIs on > how to properly fix this without breaking other things. > > =20 > > The first encoding seems to be happening in the setPath() methods of the > following classes: > > org.apache.webdav.lib.methods.GetMethod > > org.apache.webdav.lib.methods.HeadMethod > > org.apache.webdav.lib.methods.HttpRequestBodyMethodBase *** > > org.apache.webdav.lib.methods.MkcolMethod > > org.apache.webdav.lib.methods.PutMethod > > org.apache.webdav.lib.methods.UnlockMethod > > =20 > > There are several more classes derived from HttpRequestBodyMethodBase = > which > have the problem based on their extension of a base class with the = > problem: > > org.apache.webdav.lib.methods.AclMethod > > org.apache.webdav.lib.methods.AclReportMethod > > . and on and on . > > =20 > > The setPath methods in each of these looks something like this: > > /** > > * Set the path part of my request. > > * It is responsibility of the caller to ensure that the path is > > * properly encoded (URL safe). > > * > > * @param path the path to request. The path is expected > > * to be NOT URL-encoded > > * @param enc the encoding used to encode the path. UTF-8 is the > default. > > */ > > public void setPath(String path, String enc ) { > > if (enc =3D=3D null) enc =3D "UTF-8"; > > super.setPath(URLUtil.URLEncode(path, enc)); > > } > > =20 > > I have highlighted in RED an apparent disagreement in the documentation = > on > whether the paths should or should not be encoded at this point. It = > seems to > me that this should NOT be encoded based on the implementation of the > following method, which ALL these methods eventually use. > > =20 > > HttpMethodBase.generateRequestLine() line 1519 > > path =3D (requestPath =3D=3D null) ? "/" : > URIUtil.encodePath(requestPath); > > =20 > > What is happening here is that the method-specific setPath for most = > methods > are doing encoding once and it's happening again just before the = > outgoing > request is generated. > > =20 > > I believe the fix is to remove the URLUtil.URLEncode(path, enc) from = > each of > the setPath() methods in which it appears. I am going to try this out = > now > and if it works, I'll submit some patches if it does. In the mean time = > if > you know that this will break other things, or you know how to fix this > another way, please let me know. > > =20 > > Thanks. > > =20 > > Brian Johnson --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
