Bug 209508 - webdav kioslave unable to delete folder on apache dav_fs enabled webdav folder
Summary: webdav kioslave unable to delete folder on apache dav_fs enabled webdav folder
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: http (show other bugs)
Version: 4.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 184923 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-05 13:11 UTC by Martin van Es
Modified: 2013-06-03 17:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch making the directory deletion work for the WebDAV kio slave. (693 bytes, patch)
2010-01-29 15:28 UTC, Fabian Moser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin van Es 2009-10-05 13:11:14 UTC
Version:            (using KDE 4.3.1)
OS:                Linux
Installed from:    Ubuntu Packages

I created a standard Apache (2.2) webdav folder (using mod dav_fs) on my server. If I open this folder using the webdav kioslave I can create files and folders and delete files. I can not delete folders however, the error I receive is: "An unexpected error (301) occurred while attempting to retrieve the contents of the specified file or folder."
I can delete the folder on the server (as the apache user) without any problems, the folder is owned by the apache user, because that's how it was created in the first place.
Comment 1 Martin van Es 2009-10-05 13:18:05 UTC
A little addition: deleting a folder using DAVExplorer (the Java client) succeeds without problems.
Comment 2 Martin van Es 2009-10-06 14:43:32 UTC
Renaming a folder results in the same error.
Comment 3 Martin van Es 2009-10-07 11:50:22 UTC
Bug is still present in 4.3.2
Comment 4 Martin van Es 2009-11-28 15:10:54 UTC
I think I've found the problem.
When I delete the folder using konqueror the webdav kioslave sends the following command to my server:
DELETE /test HTTP/1.1

Then my server replies:
HTTP/1.1 301 Moved Permanently
Location: http://******/test/

And the directory stays where it is (no success).

DAVExplorer sends this line to my server:
DELETE /test/ HTTP/1.1

And my server replies:
HTTP/1.1 204 No Content

After that DAVExplorer asks:
PROPFIND / HTTP/1.1

And receives:
HTTP/1.1 207 Multi-Status

Containing the directory-listing xml output, without test (success).


Reading up on the RFC, the Apache server does exactly what it should do:

   There is a standing convention that when a collection is referred to
   by its name without a trailing slash, the trailing slash is
   automatically appended.  Due to this, a resource may accept a URI
   without a trailing "/" to point to a collection. In this case it
   SHOULD return a content-location header in the response pointing to
   the URI ending with the "/".  For example, if a client invokes a
   method on http://foo.bar/blah (no trailing slash), the resource
   http://foo.bar/blah/ (trailing slash) may respond as if the operation
   were invoked on it, and should return a content-location header with
   http://foo.bar/blah/ in it.  In general clients SHOULD use the "/"
   form of collection names.

In this case, Apache says that the client should look at .../test/ and Konqueror should follow that path (instead of choking). Better would be to start the DELETE request on the collection by appending the trailing / to prevent the redirection altogether.
Comment 5 Fabian Moser 2010-01-26 15:32:13 UTC
Bug is still present in 4.3.4

I can confirm the mentioned behaviour. Neither deleting nor renaming of folders is possible.
Comment 6 Fabian Moser 2010-01-29 15:28:23 UTC
Created attachment 40351 [details]
Patch making the directory deletion work for the WebDAV kio slave.

More a workaround than a solution.
Comment 7 Fabian Moser 2010-01-29 15:29:02 UTC
Correcting the delete behaviour is as simple (I have attached a patch for kdelibs 4.3.4), however correcting the renaming behaviour requires a more in-depth change.

I tried setting the UDS_DISPLAY_NAME to what UDS_NAME is now and appending a slash to the UDS_NAME for directories (webdav "collections").

Unfortunately, this solution confuses Dolphin, because he constructs the new URL of the renaming from the old URL and using setFileName. This doesn't work, because the filename can't be identified properly due to the trailing slash. In fact, the new name is simply appended to the old URL.

I have no idea what would be a clean solution.
Comment 8 Martin van Es 2010-03-04 21:01:20 UTC
This bug is still present in 4.4.1. Even getting the delete to work would be a relief IMVHO.
Comment 9 Fabian Moser 2010-03-06 00:02:56 UTC
This is a duplicate of https://bugs.kde.org/show_bug.cgi?id=187970
Comment 10 Dawit Alemayehu 2010-04-11 05:40:21 UTC
SVN commit 1113484 by adawit:

- Fixed both BR# 209508 and BR#187970. 

BUG: 209508
BUG: 187970


 M  +38 -1     http.cpp  
 M  +1 -0      http.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1113484
Comment 11 Dawit Alemayehu 2011-10-23 08:17:12 UTC
*** Bug 184923 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Eckl 2013-06-03 17:18:54 UTC
Bug still existing in KDE 4.10.3.

Uhm... wow.

access.log:
12.34.56.78 - username [03/Jun/2013:19:16:07 +0200] "DELETE /folder/subfolder HTTP/1.1" 301 250 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.10.3 (like Gecko) Konqueror/4.10"