ErrorDetails Fields

If the request-URL identifies a version history, the request MUST fail. In order to create another version history whose versions have the same content and dead properties, the appropriate sequence of VERSION-CONTROL, CHECKOUT, PUT, PROPPATCH, and CHECKIN requests must be made

The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag).

If the request-URL identifies a version, the request MUST fail.

If the request-URL identifies a resource with a DAV:checked-in property, the request MUST fail unless DAV:auto-version semantics will automatically check out the resource.

If the request attempts to modify a dead property, same semantics as PUT

If the request-URL identifies a version history, the request MUST fail.

If the request-URL identifies a version, the request MUST fail.

A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this error. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid.

The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY, and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all.

If a version-controlled resource is being checked out, it MUST have a DAV:checked-in property

If a version-controlled resource is being checked out, it MUST have a DAV:checked-out property

The request-URL MUST identify a version-controlled resource with a DAV:checked-out property.

A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource that is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property.

If the server rejects a client request because the request body contains an external entity, the server SHOULD use this error.

A server MAY fail an attempt to DELETE a version.

The number of matching principals must fall within server-specific, predefined limits. For example, this condition might be triggered if a search specification would cause the return of an extremely large number of responses.

The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. It may be that the server only supports some live properties in some parts of the repository, or simply has an internal error.

This server does not allow infinite-depth PROPFIND requests on collections.

If the request attempts to access a property defined by this document, the semantics of that property MUST be supported by the server.

The specified report MUST be supported by the resource identified by the request-URL.

If the request-URL identifies a checked-out version-controlled resource that will be automatically checked in when the lock is removed, then the versions identified by the DAV:predecessor-set of the checked-out resource MUST be descendants of the root version of the version history for the DAV:checked-out version.