Class CalDavForbiddenException

All Implemented Interfaces:
Serializable

public class CalDavForbiddenException extends CalDavException
The server accepted the credentials and refused the write anyway: a 403 on a PUT or a DELETE, which is how a CalDAV server says "this resource is not yours to change".

Distinguished from its parent CalDavException for the reason the other two subclasses are — the caller reacts differently. A plain CalDavException says this call did not work and may work next time; a 403 on a write says the account has no write privilege on that collection, which is a property of the collection and not of the attempt. Observed live on Stalwart 0.16 (EXO-90235): a calendar a colleague shared read-only had been materialised as the user's own, and every edit pushed into it was refused with 403 and retried, five times over twenty-five minutes, for a refusal the server was never going to withdraw.

Only the write verbs ever raise this. On the read verbs a 403 is classified as a credential refusal before any status policy runs, because BlueMind answers 403 for refused Basic auth on a PROPFIND — see HttpCalDavClient.checkAuthStatus — so a read that reaches the generic refusal never carries a 403.

Nothing in the body is parsed. RFC 3744 §7.1.1 requires a 403 answered for insufficient privileges to carry a DAV:error element with a DAV:need-privileges naming what was missing; neither of the two servers this add-on is verified against was captured doing so, and the status alone is what the engine acts on.

See Also:
  • Constructor Details

    • CalDavForbiddenException

      public CalDavForbiddenException(String message)
      A refused write explained by its message alone — the status naming the method and URI it answered.
      Parameters:
      message - what went wrong, in server-and-URL terms