In org.apache.webdav.lib.methods.AclMethod (2.0beta1), line 199 checks the ace.isInherited() flag to decide whether to add the inerited tag to the request (making the new ace inherited), but line 130 checks the same flag and skips any ace with inherited == true. Line 130 is attempting to avoid submitting inherited aces that were previously retrieved from the server, but it should probably be checking that (ace.getInheritedFrom() != null) instead (I'm assuming that this is always set for an inherted ace retrieved from the server, but have not checked. If this is not true, then Ace needs a separate flag to indicate that the ace is new and should be submitted with the inherited element.)
It never makes sense to set an ACE as 'inherited' - you'd have to set it on a different URI. What _can_ make sense is to allow it to be set (or not set) as "inheritable" (i.e. things below it in the directory tree will inherit this ACE, but this ACE _at this path_ isn't actually inherited). This currently isn't possible - ACEs are always set as "inheritable". There's no way to control this in the ACL spec (last time I checked, anyway) - the ACL spec basically leaves all the semantics of ACL inheritance up to the specific server implementation. Closing as INVALID since we can't do this due to spec limitations.
How about removing the always-false logic in line 199-202 that caused me to assume that putting a <D:inherited/> tag in was a valid way to imply inheritability?
I think this is done this way because the ACL spec does actually allow you to set this (the <D:inherited/> tag is allowed by the DTD). This is only because the DTD is shared between gettings the ACL and setting it, though - the spec does not give any semantics for <inherited/> being set on a request (and, indeed, it never makes sense - you explicitly CANNOT set an inherited ACE with an ACL request - you have to set it on the path which you want to inherit FROM). So, what this part of the code does is allow you to reconstruct the ACL sent by a server - even though you can't actually set this ACL on the resource. I'll leave this open if you want, but I won't make this change as I don't consider myself sufficiently familiar with the client code any more. Hopefully someone who is will review this.
I agree that the spec says nothing about how to set inheritable (a word that only appears in the old advanced acl draft anyway) and that inherited is a related but separate concept. My re-open is pretty minor - just cleanup. Line 130 says to ignore aces with isInherited set (continue in the while loop), so there is no way for line 199 to ever be true - a good thing since writing the inherited ace in the request does not make sense as you say.
I have removed the statement that could never be reached. Above all, we agree that you cannot set an inherited ACE from a WebDAV call.