Hi Bill! I am not sure what slide client does! What I found was by monitoring the data send between my client and slide, using a tcp trace tool!
I assume that when you say UTF you mean UTF8. That is one national character is converted to %<HEX>%<HEX>. What I meant by converting twice was: First convert the UTF8 escaped href to my local character set. Then I do a normal escape and the convert from UTF8 to local again! I really believe that this is a server fault, but no one has verified this yet! /Jacob -----Original Message----- From: Bill Fung [mailto:[EMAIL PROTECTED] Sent: 14. november 2003 04:59 To: Slide Users Mailing List Subject: Re: UTF8 encoded uri and slide server [was RE: encode utf-8 -> problem with ÃÃÃ] Jacob, 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
