I got similar problem:
client: servlet using slide webdav client library server: apache with mod_dav
I try to create an UTF name folder with url-encoded name %E4%B8%AD%E6%96%87. From apache log, I found MKCOL %C3%A4%C2%B8%C2%AD%C3%A6%C2%96%C2%87
The length of folder name is doubled. But the name in log is not simply url-encode the original UTF folder name twice.
What do you mean by "convert the href from the propfind body twice"?
It seems that the webdav client library will do some *magic* conversion automatically. Anyone what's that?
Thanks.
Bill
Jacob Lund wrote:
Hi again!
I have done some investigation! If I convert the href from the propfind body twice then I get the correct result!
I think that when the propfind result is generated by the server then the href should just be escaped and not converted to UTF8 since that conversion has already been done!
I believe that this is also the reason why slide do not work properly with Microsoft web folders!
/Jacob
-----Original Message-----
From: Jacob Lund [mailto:[EMAIL PROTECTED] Sent: 12. november 2003 14:16
To: 'Slide Users Mailing List'
Subject: RE: encode utf-8 -> problem with ÃÃÃ
Hmm!
If I put a file called: /files/%c3%a6%c3%b8%c3%a5100000.txt
And the propfind on /files returns an href in the response body called /files/%C3%83%C2%A6%C3%83%C2%B8%C3%83%C2%A5100000.txt then I must be missing something!
/Jacob
-----Original Message-----
From: Julian Reschke [mailto:[EMAIL PROTECTED] Sent: 12. november 2003 14:08
To: Slide Users Mailing List
Subject: Re: encode utf-8 -> problem with ÃÃÃ
Jacob Lund wrote:
Here is what I have tried:
Put a file on the server: PUT /files/%c3%a6%c3%b8%c3%a5100000.txt HTTP/1.1 (UTF8 escaped path)
Now I do a propfind: PROPFIND /files/%C3%A6%C3%B8%C3%A5100000.txt HTTP/1.1
Here I do get a resonse 207 MultiStatus response, so the server recognice the file path.
However in the response body under displayname I get: ÃÆÃâÃâÃÂÃÆÃâÃâÃÂÃÆÃâÃâÃÂ100000.txt !!! Why is this not escaped too?? I would always assume the body would contain escaped version of national letters too!
Well, no.
In theory, the DAV:displayname property shouldn't be there at all, unless you have explicitly set it. However, Slide seems to simply auto-generate it from the last path segment (a pretty useless feature). In this case, *not* to hex-escape non-ASCII characters is the absolutely right thing to do. Or do you want a client to display hex escapes instead of national characters?
Now here comes the funny part! If I do a propfind on /files with depth 1 and the look at the response body, then the file is called: /files/%C3%83%C2%A6%C3%83%C2%B8%C3%83%C2%A5100000.txt and still with displayname: ÃÆÃâÃâÃÂÃÆÃâÃâÃÂÃÆÃâÃâÃÂ100000.txt
What this tells me is that this is a server problem!
What this tells me is that there isn't any problem at all (except for the absolute useless defaulting of DAV:displayname).
Julian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
