Merge request was proposed by xhess on GitLab, but the commit
had no content. I've solved it, possibly the same way.
For the initial commit:
Executing the second example at https://wiki.davical.org/index.php?title=PROPFIND
The "Depth: 2" header is the problem. Setting the depth header larger than 1
causes the function "compare_val_with_re" to be defined again. Now checking if
the function has already been defined fixes the problem.
case 'urn:ietf:params:xml:ns:caldav:max-resource-size': /** Ignored, since we will support arbitrary size */
this solves issue #80 (large contact photos not being accepted by the server). we might wanna think about a larger limit instead, e.g. increase the limit from 65kB to 6.5MB
- only some event attributes modified by the organizer get also modified in attendees' instances of the event,
- revoked invitations mark the according attendee's event appropriately,
- a changed event time resets all attendees' PARTSTAT to NEEDS-ACTION.
Otherwise we cannot be sure if the resource we are looking at is a
proxy. Looking at the request as we did in DAVPrincipal is wrong, as one
request can result in several resources to be examined, only some of
which may be proxies.
BTW looking at the regression test changes, I'm not sure having
calendar-proxy-read-for on proxy principals is correct, but caldav-proxy
seems to have nothing to say on that so we leave it for now.
I just don't get how it's supposed to work, but it doesn't seem to
return the expected proxy delegates. This SQL doesn't expand groups,
which is a feature, and in general we only look at the grants table and
completely disregard any default privileges the principal might have
set.
and a few more bits inspired by CalDAV/aclreports.xml:
- strict Depth header checking
- principal-match: match on dav_name if not $match_self
- principal-match can "alternatively" return resources in a collection
that belong to a principal, like a user's calendars when we query
the principal URI
we use CALDAV:schedule-foo-bar in AllowedTo, but here it causes
XMLDocument to throw a DAViCal Fatal Error: [0] Dodgy looking namespace
from 'CALDAV:schedule-send-invite'!
Only regular principals can be members in any groups, for
pseudo-principals group membership doesn't make sense. In case somebody
asks, do not return the group memberships of the parent principal but
rather provide an empty answer.
this fixes a warning when the client doesn't include a space between
content-type and charset:
LOG: WARNING:Application sent content-type of "text/vcard;charset=utf-8" instead of "text/vcard"
The previous regex failed to parse PT15M which is a valid duration.
This version more correctly implements:
https://tools.ietf.org/html/rfc5545#section-3.3.6
It isn't totally correct as it incorrectly allows:
PT10H20S
Which is invalid due to no minutes being present. Oh well.
