Open 10b14224cc opened 1 month ago
Same issue with Thunderbird. Adding a Webcal link from Radicale to Thunderbird results in an empty .ics file being returned. Only DAVx5 seems to be working with Radicale's new Webcal functionality.
feature was added by https://github.com/Kozea/Radicale/pull/1229 @leso-kn : can you please investigate
Hey there :) It's about two years in since I orignally submitted that feature. Unfortunately I do not have the time to investigate at the moment, I also didn't touch the code in a while since switching to baikal a while ago. Just letting you know so someone can pick it up.
Hello,
@Kozea so what do we do? Is someone able to pick it up?
I don't think it was a good idea to merge a FR submitted 2 years ago
I don't think it was a good idea to merge a FR submitted 2 years ago
It's at least partially working and with 3.2.0 support in the WebUI was added and working with DAVx5.
"Office 365" is a commercial client, one has to investigate on client and server side why it is not working.
Contribution is required here.
I don't think it was a good idea to merge a FR submitted 2 years ago
It's at least partially working and with 3.2.0 support in the WebUI was added and working with DAVx5.
"Office 365" is a commercial client, one has to investigate on client and server side why it is not working.
Contribution is required here.
Adding the "Office 365" provided .ICS file to Thunderbird directly works as expected.
So it's only radicale server-side problem.
Can anyone confirm that "Outlook 365" and "Thunderbird" are supporting "Webcal" at all and if so, how?
"Webcal" is only delivering a source URL to the client, not any ICS content, so it is not acting as a relay for any upstream ICS source but only sending a source URL.
Example excerpt for DAVx5 taken from server side debug log:
Request:
<?xml version="1.0"?>
<propfind xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CR="urn:ietf:params:xml:ns:carddav" xmlns:CS="http://calendarserver.org/ns/" xmlns:ICAL="http://apple.com/ns/ical/" xmlns:ns5="DAV:Push">
<prop>
<resourcetype />
<current-user-privilege-set />
<displayname />
<owner />
<CR:addressbook-description />
<CR:supported-address-data />
<C:calendar-description />
<ICAL:calendar-color />
<C:supported-calendar-component-set />
<CS:source />
<ns5:push-transports />
<ns5:topic />
</prop>
</propfind>
Response:
...
<response>
<href>/USER/feiertagebayern/</href>
<propstat>
<prop>
<resourcetype>
<CS:subscribed />
<collection />
</resourcetype>
<current-user-privilege-set>
<privilege>
<read />
</privilege>
<privilege>
<all />
</privilege>
<privilege>
<write />
</privilege>
<privilege>
<write-properties />
</privilege>
<privilege>
<write-content />
</privilege>
</current-user-privilege-set>
<displayname>Feiertage Bayern</displayname>
<owner>
<href>/USER/</href>
</owner>
<ICAL:calendar-color>#0baaf6ff</ICAL:calendar-color>
<C:supported-calendar-component-set>
<C:comp name="VTODO" />
<C:comp name="VEVENT" />
<C:comp name="VJOURNAL" />
</C:supported-calendar-component-set>
<CS:source>
<href>http://i.cal.to/ical/65/bayern/feiertage/499a5ad5.07785850-d8e6092a.ics</href>
</CS:source>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
...
The ICS content must be downloaded by the client itself, honoring the CS:source
Looks like "Thunderbird" is detecting this as a normal calendar, but server has no ICS content.
When I curl my.radicale.instance/webcal-href, I get a empty ics file. If we "just" send a 302 response redirecting to the actual source, clients should just work as if they requested the actual resource?
https://en.m.wikipedia.org/wiki/Webcal
From my reading of what webcal is meant to be, the feature works as is supposed to, and clients should accordingly pull the actual data from the url in the response.
https://stackoverflow.com/a/66647917 suggests webcal:// is an unofficial protocol (fwiw, my iPad works perfectly with the webcal, so its seems to be correctly implemented)
So effectively, clients see the https:// protocol and assume they'll get a ics file, whereas the server only returns a empty ics file.
So effectively, clients see the https:// protocol and assume they'll get a ics file, whereas the server only returns a empty ics file.
That's not the case imho...client get on discovery a proper response, but not honoring it proper (at leasts not Thunderbird, which means, the WebCal resource is equal to normal collections on same server).
See also:
DAVx5: https://manual.davx5.com/accounts_collections.html#webcal-integration
I have a Office 365 calendar.
From https://outlook.office.com/calendar, Igo to wheel->calendar->share calendar, copy the .ICS URL of the calendar, and set it up as a Webcal calendar on Radicale 3.7.0
However, the URL I get back from radicale (in the form http://localhost:5232/USERNAME/CALENDAR-ID/) always return an empty ICS file