Improve error message via a GET request for ICS subscriptions not using ICSx⁵

[ymollard]

I tried to use DAVx⁵ to subscribe to 3 different ICS calendars, before finding in the FAQ that it was a job for ICSx⁵. My question addresses the error message returned by DAVx⁵ in this situation. Let me elaborate:

The first server replies 404 to PROPFIND but 200 to GET:

$ curl -IX PROPFIND https://SERVER1/someURL.ics -H "Content-Type: text/calendar"
HTTP/2 404 

$ curl -IX GET https://SERVER1/someURL.ics -H "Content-Type: text/calendar"
HTTP/2 200 

The second answers 405 to PROPFIND but 200 to GET:

$ curl -IX PROPFIND https://SERVER2/someURL -H "Content-Type: text/calendar"
HTTP/2 405 

$ curl -IX PROPFIND https://SERVER2/someURL -H "Content-Type: text/calendar"
HTTP/2 200 

The third is opendata so I can give the full URL. It answers 405 to PROPFIND, 302 to GET, and finally 405 when making a PROFIND again with the GitHub URL returned by the GET:

$ curl -IX PROPFIND https://www.data.gouv.fr/fr/datasets/r/15366b3e-70ec-4fe5-8ed4-2cd6cf28b38b -H "Content-Type: text/calendar"
HTTP/1.1 405 METHOD NOT ALLOWED
server: nginx
date: Sat, 30 Mar 2024 01:08:53 GMT
content-type: text/html; charset=utf-8
content-length: 153
allow: GET, OPTIONS, HEAD
access-control-allow-origin: *

$ curl -IX GET https://www.data.gouv.fr/fr/datasets/r/15366b3e-70ec-4fe5-8ed4-2cd6cf28b38b -H "Content-Type: text/calendar"
HTTP/1.1 302 FOUND
server: nginx
date: Sat, 30 Mar 2024 01:08:32 GMT
content-type: text/html; charset=utf-8
content-length: 347
location: https://etalab.github.io/jours-feries-france-data/ics/jours_feries_metropole.ics
access-control-allow-origin: *
pragma: public
cache-control: public
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN

$ curl -IX PROPFIND https://etalab.github.io/jours-feries-france-data/ics/jours_feries_metropole.ics -H "Content-Type: text/calendar"
HTTP/2 405 

In all 3 situations, DavX5 fails to detect that the URL should be used with ICSx5 instead.

My question here is 2-fold:

1. Can the default failure message "no possible access to caldav or carddav service" be improved to bring more help to the user?
2. Should DAVx⁵ also perform a GET fallback request and follow redirections to discriminate whether this URL is for ICSx⁵ instead, to make the message even more meaningful?

The FAQ reports that it can detect some misuses:

Since DAVx⁵ 1.8, DAVx⁵ can detect CalDAV-advertised Webcal feeds and integrate them using ICSx⁵.