Version: (using KDE KDE 3.5.6) Installed from: Ubuntu Packages OS: Linux When connecting using webdav to a remote folder, client issues a PROPFIND which give him list of files along with their "display name" and their "url". The later ones are properly encoded for server to handle them. However, webdav client from kde disregard the provided url and badly decod the display name if it's utf-8 encoded. Example: A folder contains 1 document named "1mission-Mélanome malin-09-07-2007.pdf". The server send a response to folder propfind using utf-8 encoding (Content-Type: text/xml;charset=UTF-8 and <?xml version="1.0" encoding="UTF-8"?>). The document entry is as follow: <D:response xmlns:D="DAV:"> <D:href>/intranet/DAV/files/00/missions_test/1mission-M%C3%A9lanome%20malin-09-07-2007.pdf</D:href> <D:propstat> <D:prop> <D:displayname>1mission-M..lanome malin-09-07-2007.pdf</D:displayname> <sniped a part. The display name contains a 2 byte character for é, as UTF-8 encodes it> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> As a result: 1) the display name showed in konqueror is wrong (1mission-Mélanome malin-09-07-2007). It show the artefact of deconding UTF-8 french accent using ISO-8859 encoding. Bad! 2) when i click the link, webdav client tries to get document /intranet/DAV/files/00/missions_test/1mission-M%C3%83%C2%A9lanome%20malin-09-07-2007.pdf Which has nothing to do with the one provided in d:href. The server then naturally answer with 'HTTP 404' The worse part is that webdav client does everything in ISO-8859 without any real reason to ignore what server tells it, but during discussion with server client always say it can understand "only utf-8": GET /intranet/DAV/files/00/missions_test/1mission-M%C3%83%C2%A9lanome%20malin-09-07-2007.pdf HTTP/1.1 User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.6 (like Gecko) (Kubuntu) Accept: application/pdf, */*;q=0.5 Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5 Accept-Language: fr, en Host: localhost:8080 Cookie: JSESSIONID=1DDDE66D42771BEC7BA286607383287F Connection: Keep-Alive As a result, if server uses UTF-8 character encoding to support wide range of character, the kde webdav client can not accent documents that have caracters outside the US-ASCII set. A correct behaviour would be to use the href provided by server, which should be understandable by the server that created it, instead of trying to build your own version. It's should be as following <a href=".."> in a webpage. known workaround: If you can afford it's installation, use nautilus to access non US DAV server :(
I can confirm this problem. German Umlauts in Filenames are garbled in konqueror (3.5.6) if I try to access webdav (running on apache 2.2.4). I didn't inspect the protocol stream, but I suppose that it's a bug in konqueror, since it works without problems using cadaver (a commandline webdav client) or using Windows.
I can confirm the bug too with KDE 3.5.6 & Apache 2. Other webdav clients (including Windows/Explorer) does not have this behaviour. It is quite annoying.
While looking at kdelibs-3.5.6/kioslave/http/http.cc, I hack around line 755 (KDE 3.5.6) and found that forcing encoding to 106 (utf8) give a good reading. All file and directories appear with correct encoding. But browsing inside those directories still does not work : url sent is not prperly encoded and server answer 404 (not found). Moreover, using konqueror menu tools=>select remote encoding, freeze Konqueror when using webdav....
Created attachment 22151 [details] WebDAV request by Konqueror and Apache response in UTF-8 To almost quote my namesake Sebastien Renard, I can confirm the bug too with KDE 3.5.2 & Apache 2. Other webdav clients (Nautilus or Windows/Explorer) do not have this behaviour. It is quite annoying. What I can't believe is why the bug status is still shown as unconfirmed. I hope this will be changed soon, and of course I'd like a fix to appear too (so I'll vote for this bug). Maybe this will help to finally confirm it: I've run a test on a directory containing only one file, "Tést.txt" (shown as "Tést.txt" by Konqueror), and used Wireshark to sniff the communication. Here is the key part, a request and response in which both in the Content-Type header and in the XML header mark the content as UTF-8. I've edited the host out and converted line breaks to Windows and added two new lines between the request and response for clarity, otherwise the communication is unchanged. See the attachment.
*** This bug has been marked as a duplicate of 127251 ***