On 29 Jun 2020, at 12:10, Ruediger Pluem <rpl...@apache.org> wrote:
>> + result = dav_run_deliver_report(r, resource, doc,
>> + r->output_filters, &err);
>> + switch (result) {
>> + case OK:
>> return DONE;
>
> What happens if err != NULL. Should we handle that here like in the default
> case or
> should the hook implementer ensure to not return OK if err != NULL?
Hmmm… this needs tightening up.
>> + case DECLINED:
>> + /* No one handled the report */
>> + return HTTP_NOT_IMPLEMENTED;
>
> Previously we were returning DECLINED in case there was no vsn_hooks and thus
> nothing to report. Now we return
> HTTP_NOT_IMPLEMENTED. Why this change?
When mod_dav was written, it was assumed that the REPORT method was exclusive
to https://tools.ietf.org/html/rfc3253. As a result, if a versioning
implementation was present, the versioning implementation (eg svn) was expected
to handle REPORT, and no other.
Other WebDAV extensions arrived, and they also used REPORT. But if a versioning
implementation was present, that implementation would consume the report, not
recognise the report, and then return an error. The mod_caldav code that Nokia
worked on in the late 2000s hacked around this by reading the REPORT body
first, then creating an input filter to re-insert the body if mod_caldav
realised the REPORT wasn’t for it. Parsing XML bodies over and over is very
ugly.
What this change does is formally recognise in code that multiple RFCs handle
the REPORT method. We parse the XML body, then offer this parsed body to anyone
who wants it via the deliver_report hook. Modules get their chance to handle
the report. As a last resort, the mod_dav core passes the body to the
versioning implementaton (eg svn) which then responds as previous, maintaining
existing behaviour.
To answer you direct question above, at the point we return
HTTP_NOT_IMPLEMENTED we have consumed the REPORT body. We can’t return DECLINED
in this case.
There are a significant number of RFCs that mod_dav doesn't support, such as
https://tools.ietf.org/html/rfc5689. We have RFC compliance work to do.
Regards,
Graham
—
