DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41834>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41834 Summary: Depth handling oddities in WebdavResource.copyMethod() Product: Slide Version: 2.1 Platform: Other OS/Version: Linux Status: NEW Keywords: PatchAvailable, RFC Severity: minor Priority: P2 Component: WebDAV client AssignedTo: slide-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've run into a couple oddities related to how WebdavResource.copyMethod() handles depth. First, I've found that a WebdavResource's copyMethod(String) always seems to send a request with a header of "Depth: Infinity", even if the WebdavResource is not a collection and its default depth is set to 0. This seems a bit silly, but it's not a bug per se. Second, the header "Depth: Infinity" appears to be problematic to some WebDAV servers, in particular ones based on the Python twisted.web2.dav code. Twisted WebDAV servers will respond to any COPY request with this header set with an HTTP 400 status. Changing the header to "Depth: infinity" using the attached patch resolves the problem. While it is true that servers should be somewhat forgiving of input, my reading of section 9.2 of RFC2518 is that it does not *require* the server to be case-insensitive of Depth header values. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
