Revision to url escaping patch

[Michael Smith <ms...@xn.com.au>]

The second patch I suggested (to WebdavMethodBase) turns out to have
some problems - it means that the path is stored in the object as an
already-encoded string. As a result, other things trying to read it get
the 'wrong' version - they actually want to get the non-escaped string.
Although the webdav stuff works with the other version, it can easily
fail (and does in code here which extends the methods for additional
purposes)

So, instead I suggest this patch, which does the escaping later - when
it actually needs to output the escaped string (again, this doesn't
actually supply the code for URL encoding, since I don't know where that
best belongs):

Michael

--- WebdavMethodBase.java	2001/02/05 18:20:14	1.10
+++ WebdavMethodBase.java	2001/02/15 06:31:36
@@ -480,7 +481,7 @@
      */
     public final String generateRequestLine() {
 
-        return (getName() + " " + path + " " + PROTOCOL + "\r\n");
+        return (getName() + " " + URLEncode(path) + " " + PROTOCOL +
"\r\n");
 
     }

Re: Revision to url escaping patch

[Remy Maucherat <re...@apache.org>]

> > As you suggested, I moved the utils classes to another place, so now
they
> > are actually shared between the Slide components, which is way better.
The
> > compiled classes are not shared though (they are included in both
slide.jar
> > and webdavlib.jar).
> > This produced
> >
> > I also applied your client URL encoding (and decoding) patch. Thanks !
>
> Thanks. This looks good to me. Much saner :-)
>
> Also, MoveMethod.java:202 - we should URL encode the destination header.
> Likewise in CopyMethod, for the same header. I haven't tested this, but
> it's pretty obvious that it's required (since the server DOES url decode
> that header). I don't currently use move/copy from the webdav client
> library, but this seems like the right fix.

Yes.
I'll check to see if there are other places that need encoding / decoding.

Remy

Re: Revision to url escaping patch

[Michael Smith <ms...@xn.com.au>]

> As you suggested, I moved the utils classes to another place, so now they
> are actually shared between the Slide components, which is way better. The
> compiled classes are not shared though (they are included in both slide.jar
> and webdavlib.jar).
> This produced
> 
> I also applied your client URL encoding (and decoding) patch. Thanks !

Thanks. This looks good to me. Much saner :-)

Also, MoveMethod.java:202 - we should URL encode the destination header.
Likewise in CopyMethod, for the same header. I haven't tested this, but
it's pretty obvious that it's required (since the server DOES url decode
that header). I don't currently use move/copy from the webdav client
library, but this seems like the right fix.

Michael

Re: Revision to url escaping patch

[Remy Maucherat <re...@apache.org>]

> The second patch I suggested (to WebdavMethodBase) turns out to have
> some problems - it means that the path is stored in the object as an
> already-encoded string. As a result, other things trying to read it get
> the 'wrong' version - they actually want to get the non-escaped string.
> Although the webdav stuff works with the other version, it can easily
> fail (and does in code here which extends the methods for additional
> purposes)
>
> So, instead I suggest this patch, which does the escaping later - when
> it actually needs to output the escaped string (again, this doesn't
> actually supply the code for URL encoding, since I don't know where that
> best belongs):

As you suggested, I moved the utils classes to another place, so now they
are actually shared between the Slide components, which is way better. The
compiled classes are not shared though (they are included in both slide.jar
and webdavlib.jar).
This produced

I also applied your client URL encoding (and decoding) patch. Thanks !

Remy