I can reproduce it with 4.2rc1

I confirm that this bug is still in 4.2-1 from debian packages. This has been tested from 2 computers running KDE 4.2. The exact error returned by dolphin is:
"An unexpected error (301) occured while attempting to retrieve the contents of the specified file or folder."

I can also confirm that this bug was not present in 3.5.10, so this is actually a regression from kde 3.x

This bug is still in KDE 4.2.1

The problem is with the URL specified to the kio http slave del method. If the URL for a collection does not end with a trailing "/", apache returns a HTTP 301 (Moved Permanently) and says that the new url is the same, but with a "/" appended at the end.

For example:
DELETE /webdav/testing HTTP/1.1
Host: http://xxx
...
Return:
HTTP/1.1 301 Moved Permanentrly
...
<p>The document has moved <a href="http://xxx/webdav/testing/">here</a>.</p>

Still in KDE 4.3.2
Is somebody even reading these bugs?

> Still in KDE 4.3.2
> Is somebody even reading these bugs?

Yes.  In fact an entire mailing list is dedicated to kdelibs bugs.

Ok, so I found that bug http://bugs.kde.org/show_bug.cgi?id=119066 is very similar to this one.

The fix to the bug seems to have been lost somewhere in the port to KDE4.

Never ever had such a problem with neither KDE 4.4 nor KDE 4.5 with webdavs protocol (I admit I never used the functionality before 4.4 however).

Could this be due to some incorrect server settings?

I confirm that webdav delete is working with KDE 4.5. This was probably fixed with the patch from bug 119066. I only find it odd that a workaround was added instead of fixing kio to correctly implement the dav rfc.

Sorry, I said something wrong. This bug is NOT fixed in KDE 4.5.1. I was testing with a normal file instead of a directory. As has been already said, all delete/move requests on a collection should always end with a trailing slash, but kio doesn't seem to implement the dav rfc correctly.

Here is the requests kio is sending to the dav server to create a collection:
MKCOL /test HTTP/1.1
PROPFIND / HTTP/1.1
And then to delete the collection:
DELETE /test HTTP/1.1
DELETE /test/ HTTP/1.1
DELETE /test/ HTTP/1.1

After the 2nd request, Dolphin is asking again for the password to the dav (even if the password was already entered) and the 3rd request succeeds. The hack from KDE 3.5 seems to have been added to KDE4 (will probably be removed again in KDE5).

from kdelibs/kioslave/http/http.cpp, HTTPProtocol::del method (similar hack in HTTPProtocol::rename and maybe other methods):

1432      // Work around strict Apache-2 WebDAV implementation which refuses to cooperate
1433	  // with webdav://host/directory, instead requiring webdav://host/directory/
1434	  // (strangely enough it accepts Destination: without a trailing slash)
1435	  // See BR# 209508 and BR#187970.
1436	  if (m_request.responseCode == 301) {
1437	    m_request.url = m_request.redirectUrl;
1438	    m_request.method = HTTP_DELETE;
1439	    m_request.url.setQuery(QString());;
1440	    m_request.cacheTag.policy = CC_Reload;
1441	    // force re-authentication...
1442	    delete m_wwwAuth;
1443	    m_wwwAuth = 0;
1444	    proceedUntilResponseHeader();
1445	  }

The authentication bug is obvious...

As for the correct implementation, from RFC4918:
There is a standing convention that when a collection is referred to by its name without a trailing slash, the server MAY handle the request as if the trailing slash were present. [...] In general, clients should use the trailing slash form of collection names. If clients do not use the trailing slash form the client needs to be prepared to see a redirect response.

So, from the RFC, since the first url requested is incorrect, this is not a workaround, but the correct implementation to handle the redirect. So the implementation should be modified to always include trailing slash on collection operations or the comment should be modified to reflect the fact that this is not a workaround, but a required fix to handle the dav rfc correctly.

@Diego: it's not a server configuration problem. Apache it's very simple to configure and you can't act on a "/" missed

The bug is not in KDE 4.5 anymore :) .