Hello,
We found the problem, when we were using German Umlaute in webFolders and
Office. Both client and server were running on the same machine, therefore
the fix seams to work.
I have noticed following (via protocol sniffers):
1) WebFolders sends a German "ue" as %fc, this is exactly what the java.net
classes de/en-code the "ue" to/from.
2) Office can read this %fc and displays it as an "ue", but (depending on
the request) sends sometimes %fc or a different encoded character tuple on
other requests, which Slide was able to handle.
Encoding an "ue" (in the XML propFind response encoded via utf-8) as %fc is
definitely wrong, but did work (strange). This would be the right UTF-8
encoding for B"ue"cher (hope it goes through the e-mail): B"�1/4"cher.
(hex: C3 BC)
This whole I18N stuff is really ....
The http standard states, that an URL may not contain anything except
USASCII, but (for the integration in the file system) at the user level, he
can specify more than USASCII. This standard would allow us to reject URLs
containing "special" characters.
What do you think about following idea:
If the url is send/received via the header/command part we de/en-code it via
the java.net class ("ue" <--> %fc).
If the url is wrapped in xml (e.g. propFind) we encode it via utf-8.
Best regards
Juergen
We are starting to build up a test suite for I18N, this is unfortunately a
rather slow process, for all these layers and different clients involved.
-----Original Message-----
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 11, 2001 05.39 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-slide/src/webdav/server/org/apache/slide/webdav WebdavUtils.java
> > So I would revert the patch in the meantime (since it creates problems).
> > Maybe we can come up with a decent solution (although I have no idea
what).
>
> Ok. Right now, I'm running a locally modified version which has this
> patch reverted, and also changes the decode function (in the same file)
> to use URLUtil.URLDecode(), rather than java.net.URLDecoder. This change
> I'm not so sure about, since I don't know what uses this code, so I'll
> throw a few more tests at it, look at the code a bit more closely, and
> if everything looks good I'll commit it later today.
+1.
> I'll also try and think up a real solution - "break if we get non-ASCII
> characters" is not a terribly good way of behaving ;-)
I agree :-)
Remy
