Open WhyNotHugo opened 1 year ago
Note that calendar access itself does work, it's merely not advertised.
So when I try to check whether the URL is correct, the result is false, but when I try to use it assuming it is correct, it works.
I should have specified for completeness's sake, the DAV
header contains the following value:
1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, nextcloud-checksum-update, nc-calendar-search, nc-enable-birthday-calendar
This is also true for the addressbook
entry.
For CalDAV see: RFC 4791, Calendar Access Support
A server supporting the features described in this document MUST include "calendar-access" as a field in the DAV response header from an OPTIONS request on any resource that supports any calendar properties, reports, method, or privilege. A value of "calendar- access" in the DAV response header MUST indicate that the server supports all MUST level requirements specified in this document.
For CardDAV see: RFC 6352, Address Book Support
A server supporting the features described in this document MUST include "addressbook" as a field in the DAV response header from an OPTIONS request on any resource that supports any address book properties, reports, or methods. A value of "addressbook" in the DAV response header MUST indicate that the server supports all MUST level requirements and REQUIRED features specified in this document.
Can't reproduce in v29.0.9
# curl -I -X OPTIONS -u "user:pass" https://my.cloud.com/remote.php/caldav
...
dav: 1, 3, extended-mkcol, calendar-access, calendar-proxy, access-control, calendarserver-principal-property-search, calendar-auto-schedule, calendar-availability
...
And for carddav:
# curl -I -X OPTIONS -u "user:pass" https://my.cloud.com/remote.php/carddav
...
dav: 1, 3, extended-mkcol, addressbook, access-control, calendarserver-principal-property-search
...
Can you try also:
# curl -I -X OPTIONS -u "user:pass" https://my.cloud.com/remote.php/dav
If I recall correctly, that's the URL returned as current-user-principal, and the resource is where I'm querying the CALDAV:calendar-home-set
property.
Hum. I'm not a specialist in this area, please wait for someone who can verify this behavior 👍
⚠️ This issue respects the following points: ⚠️
Bug description
I'm writing a function to check whether a given URL corresponds to a server supporting CALDAV or not. For this, I'm checking the
DAV
URL as specified in rfc4791#section-5.1:The URL (https://example.com/remote.php/dav) does support calendar access; I can successfully use
REPORT
to fetch calendar resources andPROPFIND
to enumerate calendar resources and collections, so I'm quite sure I have the right URL.Steps to reproduce
OPTIONS
http request.Expected behavior
The
DAV
header should containcalendar-access
.Installation method
Other Community project
I don't have access to the server installation; I only have a test account which someone is lending me to test NextCloud support. As such, I don't have most of the below details.
Operating system
Other
PHP engine version
Other
Web server
Other
Database engine version
Other
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
Version from the about screen:
(I'm not entirely sure why, but text selection for copy-pasting was not possible).