0

I want to add a ics link in my website. Users would be able to add this url to their favorite calendar app and see their upcoming events.

My users use my website for a few months and then leave (it's a educational website). So my question is :

Is there a way (in the ics protocol maybe ?) to automatically unsubscribe my users from my ics url to avoid unecessary requests "for life"?

For exemple, iCal on Mac will do a request every hour to the url to get new data. But once a user leave, there will never be new data, so the requests are useless.

Thanks for your help!

Mathieu Mahé
  • 2,647
  • 3
  • 35
  • 50
  • They just download the .ics file? And all users link to the same file? – CodeCaster Mar 03 '20 at 10:53
  • It's not a file, it's a url and everyone has its proper url (something like /events.ics?token=token-of-the-user). Having an url instead of a file let me be more flexible (adding an event or change a location of an event) without having the user to add another file to its calendar – Mathieu Mahé Mar 03 '20 at 11:03
  • Sooo does some serverside code run behind the .ics URL? You're going to have to give us more information here. You can't make a client automatically remove the URL registration from their client, but you can stuff with caching or status codes if memory serves me right. – CodeCaster Mar 03 '20 at 11:29
  • Yes, there is server side code behind the url. I will have some caching policy to avoid generating the data too often. But I want to know if it's possible to "stop" the ical client from requesting the url. – Mathieu Mahé Mar 03 '20 at 11:37
  • See answer provided (use http codes) to similar question here https://stackoverflow.com/questions/60022347/how-can-an-ics-vcalendar-file-be-marked-as-end-of-life-no-longer-synced/60049810?noredirect=1#comment106221315_60049810 – anmari Mar 05 '20 at 04:55
  • You'd have to have an ics feed per user, then serve up whatever http code is appropriate for that user. – anmari Mar 05 '20 at 06:01
  • Thanks for the answer but, sadly, it doesn't work (at least with calendar on Mac). 404 and 410 have no effects. – Mathieu Mahé Mar 06 '20 at 15:45
  • That may be a problem with the calendar app then. Bit like dead link handling. It may be that they cache it for the history? perhaps check the access log to see whether app is looking for updates files on that url or not. – anmari Mar 10 '20 at 23:34
  • as per google calendar when the app attempts to sync the calendar, it should report the http error. May require human intervention to then delete the calendar subscription. https://support.google.com/calendar/forum/AAAAd3GaXpEphPuCRXiJXc – anmari Mar 10 '20 at 23:53
  • And again with apple if the url is actually returning an http error, then the apple device should show the http error https://apple.stackexchange.com/questions/338085/mac-calendar-app-ical-displays-error-message-server-responded-with-an-error – anmari Mar 10 '20 at 23:55

1 Answers1

0

You can either ask people to unsubscribe, make it desirable perhaps by a dummy daily event that says ' No longer updated, please unsubscribe'

OR

force an unsubscribe by returning an appropriate http return code to the requesting system - probably the 410 (gone) rather than the 404. The 410, as per it's description ,is the most appropriate: "The url is no longer there and the condition is likely to be permanent." https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410

A url could be offered per user. Ensure that it then returns a 410 at end of life (not just an empty file)

The receiving devices don't just quietly unsubscribe the url. Usually they show the error. Ideally the human should unsubscribe. Perhaps an email with quick tips on how to unsubcribe may be best for your situation? at least then you've told them.

I find even for myself I have a lot of garbage calendar urls in my calendar app. If I started getting errors I would unsubscribe them (or if there was garbage events, I might unsubscribe or 'hide' it.

Other ways of conveying information to the requesting app, that may reduce load on your server:

Last Modified in the header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After (No 'never'!)

There are also unofficial (non RFC5545) extensions that you could include in the ics file: eg: X-PUBLISHED-TTL - Recommended update interval for subscription to the calendar. One could make that a really long interval. See https://en.wikipedia.org/wiki/ICalendar#Calendar_extensions

anmari
  • 3,830
  • 1
  • 15
  • 15