[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #19 from Michael Osipov --- (In reply to Mark Thomas from comment #18) > Additional fix applied. Confirmed. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #18 from Mark Thomas --- Additional fix applied. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #17 from Michael Osipov --- Example: osipovmi@deblndw011x:~ $ curl --negotiate -u : -X DELETE https://example.com/backend-dev/dav/log/foo | xmllint --format - % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 412 100 4120 0 13181 0 --:--:-- --:--:-- --:--:-- 13290 /backend-dev/dav/log/foo/bar HTTP/1.1 405 /backend-dev/dav/log/foo/baz/moo HTTP/1.1 405 /backend-dev/dav/log/foo HTTP/1.1 405 The last response should be there since it is the parent (root) collection, no? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362
--- Comment #16 from Michael Osipov ---
(In reply to Mark Thomas from comment #15)
> Fixed in:
> - 11.0.x for 11.0.0 onwards
> - 10.1.x for 10.1.31 onwards
> - 9.0.x for 9.0.96 onwards
Thank your for the fix, are you sure this is complete?
What about this spot?
deleteCollection(req, path, errorList);
if (!resource.delete()) {
errorList.put(path,
Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
}
Collection could not be deleted and the parent resource as well. In this case
the parent shouldn't appear in the list, but it does. Am I wrong?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Mark Thomas --- Fixed in: - 11.0.x for 11.0.0 onwards - 10.1.x for 10.1.31 onwards - 9.0.x for 9.0.96 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #14 from Mark Thomas --- I have a fix for the comment and the empty directory issue ready to commit. I just need to run the WebDAV test suite to make sure I haven't broken anything. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362
--- Comment #13 from Michael Osipov ---
(In reply to Michael Osipov from comment #12)
> (In reply to Christopher Schultz from comment #11)
> > (In reply to Mark Thomas from comment #6)
> > > Final paragraph of 9.6.1.
> >
> > Also, the complete example in 9.6.2 includes this specific case, and only
> > includes the file and not its parent directory in the response.
>
> This means that our current implementation is not correct for the
> Request-URI collection:
> > Map errorList = new LinkedHashMap<>();
> >
> > deleteCollection(req, path, errorList);
> > if (!resource.delete()) {
> > errorList.put(path,
> > Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
> > }
> >
> > if (!errorList.isEmpty()) {
> > sendReport(req, resp, errorList);
> > return false;
> > }
>
> Based you your comment we need to do:
> > -if (!resource.delete()) {
> > -errorList.put(path,
> > Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
> > -}
> > +resource.delete();
this patch is incorrect because if we consider that the collection is empty,
but deleting the collection fails the client would never see an error. This is
a separate issue which should be reported and handled separately. Here, I will
stick to the comment update only.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362
--- Comment #12 from Michael Osipov ---
(In reply to Christopher Schultz from comment #11)
> (In reply to Mark Thomas from comment #6)
> > Final paragraph of 9.6.1.
>
> Also, the complete example in 9.6.2 includes this specific case, and only
> includes the file and not its parent directory in the response.
This means that our current implementation is not correct for the Request-URI
collection:
> Map errorList = new LinkedHashMap<>();
>
> deleteCollection(req, path, errorList);
> if (!resource.delete()) {
> errorList.put(path,
> Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
> }
>
> if (!errorList.isEmpty()) {
> sendReport(req, resp, errorList);
> return false;
> }
Based you your comment we need to do:
> -if (!resource.delete()) {
> -errorList.put(path,
> Integer.valueOf(WebdavStatus.SC_METHOD_NOT_ALLOWED));
> -}
> +resource.delete();
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #11 from Christopher Schultz --- (In reply to Mark Thomas from comment #6) > Final paragraph of 9.6.1. Also, the complete example in 9.6.2 includes this specific case, and only includes the file and not its parent directory in the response. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #10 from Michael Osipov --- (In reply to Mark Thomas from comment #9) > My reading of RFC 4918 is if we have a status code for baz it should be 424. > > Quoting from RFC 2119: >SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that >there may exist valid reasons in particular circumstances when the >particular behavior is acceptable or even useful, but the full >implications should be understood and the case carefully weighed >before implementing any behavior described with this label. > > If we have valid reasons to include a status code it should be 424. My > preference is for your counter proposal to add a comment and continue to > omit the status for parent resources in this case. This is what my counter-proposal does, not behavioral change, just add better docs. That's it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #9 from Mark Thomas --- My reading of RFC 4918 is if we have a status code for baz it should be 424. Quoting from RFC 2119: SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. If we have valid reasons to include a status code it should be 424. My preference is for your counter proposal to add a comment and continue to omit the status for parent resources in this case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362
--- Comment #8 from Michael Osipov ---
My counter-proposal for code clarity:
> diff --git a/java/org/apache/catalina/servlets/WebdavServlet.java
> b/java/org/apache/catalina/servlets/WebdavServlet.java
> index e8cb718295..22df7343af 100644
> --- a/java/org/apache/catalina/servlets/WebdavServlet.java
> +++ b/java/org/apache/catalina/servlets/WebdavServlet.java
> @@ -1765,9 +1765,11 @@ public class WebdavServlet extends DefaultServlet
> implements PeriodicEventListen
> }
>
> if (!childResource.delete()) {
> +/* According to RFC 4918, section 9.6.1, last paragraph
> the multi-status response
> + * SHOULD NOT contain the failed ancestor resource
> collection because the client
> + * will know that already.
> + */
> 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));
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #7 from Michael Osipov --- (In reply to Mark Thomas from comment #6) > Final paragraph of 9.6.1. I see: 424 (Failed Dependency) status codes SHOULD NOT be in the 207 (Multi- Status) response for DELETE. They can be safely left out because the client will know that the ancestors of a resource could not be deleted when the client receives an error for the ancestor's progeny. Additionally, 204 (No Content) errors SHOULD NOT be returned in the 207 (Multi-Status). The reason for this prohibition is that 204 (No Content) is the default success code. But it says SHOULD NOT and not MUST NOT. So if we are going to retain the current behavior I would at least update the comment with this reference. So, I am still in favor, but if you still object I would just add the comment and close this ticket. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #6 from Mark Thomas --- Final paragraph of 9.6.1. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #5 from Michael Osipov --- (In reply to Mark Thomas from comment #4) > See RFC 4918 section 9.6.1. I think this should remain as is. Are you referring to: If any resource identified by a member URL cannot be deleted, then all of the member's ancestors MUST NOT be deleted, so as to maintain URL namespace consistency. Note that this does not change the behavior of DELETE, but the error reporting. Reading this: If an error occurs deleting a member resource (a resource other than the resource identified in the Request-URI), then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error code, which should help the client understand which resources caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked. I understand that the current response is incomplete. Can you please elaborate? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #4 from Mark Thomas --- See RFC 4918 section 9.6.1. I think this should remain as is. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #3 from Remy Maucherat --- (In reply to Michael Osipov from comment #2) > (In reply to Remy Maucherat from comment #1) > > It's always being like that. The reason might have been to avoid being too > > redundant (if not deleting the contents, the intermediate parent folder is > > also obviously not getting deleted) but it seems possible to add that > > although there's probably no added value. > > But what if the files can be deleted, but the directory is write-protected? > For consistency reasons I'd like to add it. Ok. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #2 from Michael Osipov --- (In reply to Remy Maucherat from comment #1) > It's always being like that. The reason might have been to avoid being too > redundant (if not deleting the contents, the intermediate parent folder is > also obviously not getting deleted) but it seems possible to add that > although there's probably no added value. But what if the files can be deleted, but the directory is write-protected? For consistency reasons I'd like to add it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 --- Comment #1 from Remy Maucherat --- It's always being like that. The reason might have been to avoid being too redundant (if not deleting the contents, the intermediate parent folder is also obviously not getting deleted) but it seems possible to add that although there's probably no added value. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69362] Recursive nested collection DELETE not reflected in multi-status report from WebdavServlet
https://bz.apache.org/bugzilla/show_bug.cgi?id=69362 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
