Patch for working MOVE, COPY operations, and a question

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

Hi all,

The webdav servlet currently doesn't properly URL-unescape the URLs
passed to it. This works fine for things like GET and PUT, because the
request location has already had the decoding done by the servlet
engine.

However, for copy and move, the Destination header remains undecoded.
This patch fixes that.

The visible change is that filenames with spaces can be correctly
copied/moved. I suppose other characters are dealt with properly too.
The microsoft client at least works correctly with this (so does the
slide command line client, but you have to do the URL-encoding manually,
at the moment at least)

This, of course, requires that the client URL-encodes the headers
correctly. Which brings me to my question: should the webdav client
libraries do this, or should the responsibility for this be upon the
calling program?

On one hand, if the client libraries don't, it makes it possible to
create the request headers incorrectly. However, if they DO, it isn't
entirely clear what they should do - they don't always know which
characters to encode, it seems to me, because at that point there is no
clear distinction between characters which are a natural part of the
URL, and characters which have to be escaped so as NOT to be interpreted
as such.

It isn't clear which way this should be done - I'll send a patch if you
guys think it should go in the client libraries.

Hope that was clear.

Michael Smith

Re: Patch for working MOVE, COPY operations, and a question

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

Quoting Michael Smith <ms...@xn.com.au>:

> Hi all,
> 
> The webdav servlet currently doesn't properly URL-unescape the URLs
> passed to it. This works fine for things like GET and PUT, because the
> request location has already had the decoding done by the servlet
> engine.
> 
> However, for copy and move, the Destination header remains undecoded.
> This patch fixes that.

Good patch !

> The visible change is that filenames with spaces can be correctly
> copied/moved. I suppose other characters are dealt with properly too.
> The microsoft client at least works correctly with this (so does the
> slide command line client, but you have to do the URL-encoding
> manually,
> at the moment at least)
> 
> This, of course, requires that the client URL-encodes the headers
> correctly. Which brings me to my question: should the webdav client
> libraries do this, or should the responsibility for this be upon the
> calling program?

The client library should do the encoding (IMO).
I think the point is to abstract the HTTP (and WebDAV) layer as much as 
possible, and URL encoding is definitely part of the HTTP layer, so it should 
be abstracted.

> On one hand, if the client libraries don't, it makes it possible to
> create the request headers incorrectly. However, if they DO, it isn't
> entirely clear what they should do - they don't always know which
> characters to encode, it seems to me, because at that point there is no
> clear distinction between characters which are a natural part of the
> URL, and characters which have to be escaped so as NOT to be
> interpreted
> as such.
> 
> It isn't clear which way this should be done - I'll send a patch if you
> guys think it should go in the client libraries.

If you have a patch for this, I'll include it. Actually, the piece of code 
which actually does the encoding (let's call that the URLEncode function) will 
also be included into Tomcat 4, as I also need URL encoding there.

Thanks,
Remy