Thetype exposes the following members.
Determines whether the specified object is equal to the current object.(Inherited from .)
Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.(Inherited from .)
Serves as the default hash function.(Inherited from .)
Gets the(Inherited from of the current instance. .)
Creates a shallow copy of the current(Inherited from . .)
Returns a string that represents the current object.(Inherited from .)
The principals specified in the ACEs submitted in the ACL request MUST be allowed as principals for the resource. For example, a server where only authenticated principals can access resources would not allow the DAV:all or DAV:unauthenticated principals to be used in an ACE, since these would allow unauthenticated access to resources.
All non-inherited deny ACEs MUST precede all non-inherited grant ACEs.
The ACEs submitted in the ACL request MUST NOT include a deny ACE. This precondition applies only when the ACL restrictions of the resource include the DAV:grant-only constraint (defined in Section 5.6.1).
(DAV:limited-number-of-aces): The number of ACEs submitted in the ACL request MUST NOT exceed the number of ACEs allowed on that resource. However, ACL-compliant servers MUST support at least one ACE granting privileges to a single principal, and one ACE granting privileges to a group.
The result of the ACL request MUST have at least one ACE for each principal identified in a DAV:required-principal XML element in the ACL semantics of that resource (see Section 5.5).
The ACL request MUST NOT attempt to grant or deny an abstract privilege (see Section 5.3).
The ACEs submitted in the ACL request MUST NOT conflict with each other. This is a catchall error code indicating that an implementation-specific ACL restriction has been violated.
The ACEs submitted in the ACL request MUST NOT conflict with the inherited ACEs on the resource. For example, if the resource inherits an ACE from its parent collection granting DAV:write to a given principal, then it would not be consistent if the ACL request submitted an ACE denying DAV:write to the same principal. Note that reporting of this error will be implementation-dependent. Implementations MUST either report this error or allow the ACE to be set, and then let normal ACE evaluation rules determine whether the new ACE has any impact on the privileges available to a specific principal.
The ACL request MUST NOT include a DAV:invert element. This precondition applies only when the ACL semantics of the resource includes the DAV:no-invert constraint (defined in Section 5.6.2).
The ACEs submitted in the ACL request MUST NOT conflict with the protected ACEs on the resource. For example, if the resource has a protected ACE granting DAV:write to a given principal, then it would not be consistent if the ACL request submitted an ACE denying DAV:write to the same principal.
The ACEs submitted in the ACL request MUST be supported by the resource.
Every principal URL in the ACL request MUST identify a principal resource.