Package org.exoplatform.caldav.client


package org.exoplatform.caldav.client
  • Class
    Description
    One access control entry of a collection's DAV:acl, as RFC 3744 §5.5 defines it: who it applies to, whether it grants or denies, which privileges, and whether the server lets it be changed (EXO-90253).
    Whom an entry applies to: one of the six forms RFC 3744 §5.5.1 allows.
    The forms of DAV:principal.
    What the server answered to an ACL request (EXO-90253): a claim, never a fact.
    The server refused the credentials.
    The CalDAV protocol, and nothing else: it fetches, it does not decide.
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.
    The one failure the CalDAV client throws for protocol and transport trouble: the server unreachable, an answer outside the accepted statuses of the verb, a body that is not DAV XML, or a target this client refuses to address.
    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".
    The server says the thing a call addressed does not exist.
    The CalDAV door: every write is the CalDavClient method of the same name, with the same headers, the same body and the same answer.
    The conversation never reached the calendar server: the transport failed outright, or a gateway standing in front of the server answered that it could not reach it either (502, 503, 504).
    One calendar collection as a PROPFIND listed it: everything the sync engine binds a pair on, and nothing it does not need.
    What one discovery walk answers: who the authenticated user is on the server, and where that user's calendars live.
    One calendar object (an .ics resource) as the server answered it.
    The door through which one calendar object is written to, or removed from, a server — the four write shapes the engine uses, and nothing else.
    Picks the door a server's copies go through: the one write-channel decision of the whole engine (EXO-90307).
    A collection's DAV:acl as the server answered it to its owner (EXO-90253), with the two facts that decide whether it may be written back.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    CalDAV over the JDK's own HTTP client, modelled line for line on email-connector's HttpCardDavClient — the hand-written client that already works against the same BlueMind that defeated the browser — with the disciplines the relay established carried over: registry-only targets — endpoints are minted from the server registry alone (HttpCalDavClient.endpoint(Long, String)), hrefs resolve against that endpoint's authority, and a foreign-host href is refused; no redirects — a declared server must not be able to bounce this client's credentialed requests to another host, so the transport never follows a 3xx (which also rules the well-known discovery flow out by design: discovery starts at the registered base path instead); explicit timeouts and a bounded body read, both deployment-tunable; no auth material anywhere near a log or an exception — every message names the method and the URI, never a header. The XML is parsed with doctypes and external entities disabled: the payload comes from whatever server an administrator declared, which is still attacker-influenced input, and a stock parser would happily read files off this machine on its behalf.
    What an MKCALENDAR answered — deliberately never a boolean "created".
    What the server answered to a PROPPATCH — the raw status and the statuses of every propstat that did not grant its property.
    What a conditional PUT answered.
    Which incremental-sync tier a collection's server can serve, read from one Depth:0 PROPFIND (supported-report-set, ctag, sync token) plus the DAV response header.
    The incremental strategies of the plan, cheapest first.
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
    What an RFC 6578 sync-collection REPORT answered: the hrefs that changed, the hrefs that are gone, and the token to store for the next run.