The Destination header must always be QUrl::FullyEncoded
so that special characters can be used as destination.
Details
- Reviewers
dfaure - Group Reviewers
Frameworks Dolphin - Commits
- R241:1f24f49baba4: Fix WebDAV destination header on COPY and MOVE operations
Diff Detail
- Repository
- R241 KIO
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Does this fix any of the bugs here? https://bugs.kde.org/buglist.cgi?component=webdav&list_id=1529637&product=kio&resolution=---
Ping? This is a pretty obvious fix, desturl is QString which later becomes latin1 loosing characters...
Test plan:
- Connecto to a WebDav server
- Create a file named "foo"
- Try to rename the file to "speçiál" - it should result in "spe"
The COPY operation has the same issue but I'm not sure how to test it right now,
probably it will also fail if the destination directory is named with special characters (non-latin1).
The test plan should be part of the commit, use "Edit revision" above.
The 3rd point is strange - it should of course result in "speçiál", everything else would be silent data corruption.
Well the issue will probably depend on the server,
for example Apache2 with Nextcloud it returns forbidden for both operations,
in Cloudlyst which does:
QUrl::fromEncoded(QStringLiteral("file:///speçiál").toLatin1()).toLocalFile();
you get a file with a different file name as URL.
Since 'ç' is extended ASCII this "fails" only because URL are sopposed
to use only printable ASCII chars
If you use some some UTF-8 char like ←it wil
produce that behavior:
QStringLiteral("spe←ail\r\n").toLatin1()
will produce:
"spe?ail\r\n"
and the question mark is interpreted as being the query part
of an URL, thus what I said before that it cuts
everything past the special char due URL parsing.
you can see doing this:
QUrl::fromEncoded(QStringLiteral("file:///file←sadssad").toLatin1()).toLocalFile()
local file will be "/file"