I think these remaining changes are due to AWLs vCalendar->GetItip()
creating a "minimal iTIP version" of events, and Jan Mate's "various
scheduling related fixes" in 31af435c and 92f48f38
PHP 7.1 throws an exception when a user-defined function is called with
too few arguments: http://php.net/manual/en/migration71.incompatible.php
As explained in the comments, collection_privilege_format_function and
principal_privilege_format_function take three arguments because of
their use as a rendering callback, however the latter two of them are
never used and thus can be ommitted in other uses.
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
