https://bz.apache.org/bugzilla/show_bug.cgi?id=69362
Bug ID: 69362
Summary: Recursive nested collection DELETE not reflected in
multi-status report from WebdavServlet
Product: Tomcat 9
Version: 9.0.95
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: -----
Consider the following tree:
# tree log/foo/
log/foo/
├── bar
└── baz
└── moo
Let's try to delete it:
osipovmi@deblndw011x:~/var/Projekte/tomcat (apache-main *=)
$ curl --negotiate -u : -X DELETE 'https://example.com/backend-dev/dav/log/foo'
| xmllint --format -
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/backend-dev/dav/log/foo/bar</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
<D:response>
<D:href>/backend-dev/dav/log/foo/baz/moo</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
<D:response>
<D:href>/backend-dev/dav/log/foo</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
</D:multistatus>
Where is the status for baz/?
Well, the problem is the following: While WebdavServlet#deleteResource() does a
proper post-order traversal and then marks the actual collection is
undeletable:
deleteCollection(req, path, errorList);
if (!resource.delete()) {
errorList.put(path,
Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
}
WebdavServlet#deleteCollection() deviates from it:
if (childResource.isDirectory()) {
deleteCollection(req, childName, errorList);
}
if (!childResource.delete()) {
if (!childResource.isDirectory()) {
// If it's not a collection, then it's an unknown
// error
errorList.put(childName,
Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
}
}
Reason: unclear. By removing the nested if clause it works:
osipovmi@deblndw011x:~/var/Projekte/tomcat (apache-9.0.x =)
$ curl --negotiate -u : -X DELETE 'https://example.com/backend-dev/dav/log/foo'
| xmllint --format -
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/backend-dev/dav/log/foo/bar</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
<D:response>
<D:href>/backend-dev/dav/log/foo/baz/moo</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
<D:response>
<D:href>/backend-dev/dav/log/foo/baz</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
<D:response>
<D:href>/backend-dev/dav/log/foo</D:href>
<D:status>HTTP/1.1 500 </D:status>
</D:response>
</D:multistatus>
Either I do not understand the reason here or it is clearly a bug.
If you (Rémy?) confirm the bug, I will push the fix.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
