Hi,
I think there is a serious bug in the way Slide handles URI encoding that I think should not go into the 2.1 release. (sorry if the email is a little long...our fairly big project depends on this working a.s.a.p)
I observed that neither Swedish nor Icelandic letters (nor Latvian for that matter) make it correctly to the Slide store (any type) when you are using the "ISO-8859-1" encoding (like most western countries) on the server.
When stepping through the WebdavServlet I noticed that the characters become a mess before "and" after a seemingly pointless "encode" that is followed directly with a "decode".
I think the problem is as follows:
In Slide there are at least two points where an uri is is encoded/decoded before being used.
1. In WebdavRessource when you try to upload a file by specifying the path and an inputstream with the method
public boolean putMethod(String path, InputStream is)
...
PutMethod method = new PutMethod(URIUtil.encodePathQuery(path));
...
As you can see by this code it encodes the path by the systems default encoding which by the way on OSX at least is the infamous MacRoman character set and unfortunaly there is no way for the developer to specify an alternative encoding here. This causes one problem right away on the server side because it tries do encode+decode the string using ISO-8859-1 and of course fails miserably.
2 So...of course I just copied all the relevant code from the putMethod to my class and tried again using
URIUtil.encodePathQuery(path,"ISO-8859-1").
This time the path makes it safely into the encoding+decoding stage in the WebDavServlet and looks like this (hope you can view Icelandic characters...)
"/files/���������-ma�ur.doc"
Then next in the service method the problem starts
protected void service(..)
...
req.setAttribute("slide_uri", WebdavUtils.getRelativePath(req, (WebdavServletConfig) getServletConfig()));
...
I don't understand why but in WebdavUtils.getRelativePath(...) the path is first encoded and then decoded back (why not use the original?).
The encoding starts....
decodeURL(fixTomcatURL(result, "UTF-8"));
Ok...so the path ,that still looks readable, first gets encoded with ISO-8859-1 (that I set in Slide.properties btw) in URLUtil.URLEncode(path, enc);
Now the string looks like this
"/files/%C3%81%C3%AD%C3%B3%C3%A9%C3%BA%C3%BE%C3%B0%C3%B6%C3%A6- ma%C3%B0ur.doc"
I don't really know if it is ok still but lets continue anyway...the last phase before the path gets totally ruined is the decodeURL part
public static String decodeURL(String path) {
return decodeURL(path, Configuration.urlEncoding());
}
(One point here. This method call gets the desired encoding right but has no backup plan like the encode part with "UTF-8" except for the current system encoding making it incompatible with the encoded string right away if it's not UTF-8)
In decodeURL(path, Configuration.urlEncoding()) you hit a brick wall. In there is a method call that destroys the path and that is
String normalized = URLUtil.URLDecode(path, enc); that leads to a return URLDecode(bytes, enc);
The final path that then gets saved (to the database in the URI table) is this poor bugger
"/files/�?�?�?̩̼�?̡̦�?-ma̡ur.doc"
and then you have a file you can't even download or a folder that you can't browse(if you where using a .mkCol(..))
So can anybody help me fix this or am I just crazy and Slide is working for everybody else (Anybody else using ISO-8859-1?)
I have a vague idea of what I think might be causing this but I would like to see the whole roundabout fixed permanently.
One idea is to always send and receive the String as UTF-8 but then change it to the desired encoding just before writing to Slide.
Best Regards
Eirikur S. Hrafnsson, [EMAIL PROTECTED] Chief Software Engineer Idega Software http://www.idega.com
On 23.12.2004, at 12:32, Daniel Florey wrote:
I've no clue how the 2.4.1 made it into the binary package. I've build the
packages and they seem to look right.
Can you check if you have some weird build.properties in your ${home} James?
I've added the mxl-im-exporter needed by the clientlib to the dist target.
Would you be so kind to build the distro for the clientlib once again?
Thanks,
Daniel
-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:slide-dev-return-15249- [EMAIL PROTECTED] Im
Auftrag von Daniel Florey
Gesendet: Donnerstag, 23. Dezember 2004 13:22
An: 'Slide Developers Mailing List'
Betreff: AW: 2.1 Release
Hi James,
The webdavclient version number is still 2.4.1 (??). Something must be
messed up with the build script.
Also the xml-im-exporter needed by the webdavclient is missing in the
distribution. I'll fix that now and would be very happy if could do the
distro again.
Cheers, Daniel
-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:slide-dev-return-15232-apmail-
[EMAIL PROTECTED] Im Auftrag von James Mason
Gesendet: Mittwoch, 22. Dezember 2004 18:17
An: Slide Developers Mailing List
Betreff: 2.1 Release
I've uploaded everything to http://cvs.apache.org/~masonjm/slide_2.1/
Can someone have a look and make sure I haven't missed anything? I want
to double check before I put this somewhere that it's going to get
mirrored :).
-James
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
