Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webcal doesn't work with Office 365 calendars #1484

Closed
10b14224cc opened this issue May 3, 2024 · 10 comments
Closed

Webcal doesn't work with Office 365 calendars #1484

10b14224cc opened this issue May 3, 2024 · 10 comments
Labels
client client related issue not our bug issues which can't be fixed on server side

Comments

@10b14224cc
Copy link

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

@j0hann3s
Copy link

j0hann3s commented May 8, 2024

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.

@pbiering pbiering added the bug label May 8, 2024
@pbiering pbiering added this to the 3.2.1 milestone May 8, 2024
@pbiering
Copy link
Collaborator

pbiering commented May 8, 2024

feature was added by #1229
@leso-kn : can you please investigate

@leso-kn
Copy link
Contributor

leso-kn commented May 14, 2024

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.

@pbiering pbiering modified the milestones: 3.2.1, 3.2.x May 14, 2024
@pbiering pbiering added the need:support support/help/contribution is required label May 14, 2024
@10b14224cc
Copy link
Author

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

@pbiering
Copy link
Collaborator

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.

@10b14224cc
Copy link
Author

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.

@pbiering
Copy link
Collaborator

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.

@DhruvaSambrani
Copy link

DhruvaSambrani commented May 28, 2024

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?

@DhruvaSambrani
Copy link

DhruvaSambrani commented May 28, 2024

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.

@pbiering
Copy link
Collaborator

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

@pbiering pbiering added not our bug issues which can't be fixed on server side client client related issue and removed bug need:support support/help/contribution is required labels May 29, 2024
@pbiering pbiering removed this from the 3.2.x milestone May 29, 2024
@Kozea Kozea locked and limited conversation to collaborators Oct 17, 2024
@pbiering pbiering converted this issue into discussion #1600 Oct 17, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
client client related issue not our bug issues which can't be fixed on server side
Projects
None yet
Development

No branches or pull requests

5 participants