Normalize results so tests work with newer and older versions
This change is similar to e565cc0a5e4af0330fe5a1ab6f2476be7fb10df4 and
following
From the Apache 2.4.35 changelog:
*) http: Enforce consistently no response body with both 204 and 304
statuses. [Yann Ylavic]
dead_properties is an assoc.array from name to value, but it was being merged
with simple arrays of property names.
This means that tests 0824 and 0828 now actually return the dead properties, so
I've updated those result files.
Signed-off-by: Jamie McClymont <jamiemcclymont@catalyst.net.nz>
Gitlab CI has a different collection_id for US Holidays than running
the tests locally. We don't actually care about ID for this test,
just the fact that the binding is present is enough for us.
In the GitLab CI environment, the command:
@header("Content-Type: text/plain");
Generates the Content-Type line of:
Content-Type: text/plain; charset=UTF-8
But on my workstation it generates this:
Content-Type: text/plain;charset=UTF-8
By adding that charset to our call to @header, we receive a
predictable result.
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.
Primary fix is the search_path to ensure that the collection table
is in the search path so that the copy into dav_binding (and
possibly others) will work.
I also suppressed the warning about plpgsql.
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.
