GNOME Bugzilla – Bug 527692
[caldav] CalDAV does not work with Apple CalDAV Server
Last modified: 2008-11-28 11:17:31 UTC
Please describe the problem: Subscribing to an Apple CalDAV Server calendar does not show any data wehn using a URL like "caldav://example.com:8008/calendars/users/username/calendar/". There is no error message, the calendar simply stays blank. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information: It seems that the Evolution/CalDAV-Plugin cuts off the tailing slash when doing a "REPORT" query, which the Apple CalDAV Server answers with a "301 Moved Permanently". As a quick workaround enter a URL like "caldav://example.com:8008/calendars/users/username/calendar/./" and the request works fine and the calendar gets populated with data.
It does not work either against the Sun CalDAV server. The initial OPTION query is missing the trailing slash so the server responds with a 404. Details below: Evolution 2.22.3.1 Configured a CalDAV calendar with the following caldav://whatsnew.demo.iplanet.com/davserver/dav/home/arnaudq/calendar/ Although the url includes a final slash, I can see the client doing an: OPTIONS /davserver/dav/home/arnaudq/calendar HTTP/1.1 (final / missing), to which the server responds with a "404 Not Found" since no such resource exists. In case you want to try it: login = arnaudq password = secret
Forgot the port number in the demo account: caldav://whatsnew.demo.iplanet.com:3080/dav/home/arnaudq/calendar/ login=arnaudq password=secret
Just to throw a few RFC's at this bug, checking RFC 2396, you can see in the steps described in 5.2 that a trailling '/' would not be removed from a URL by correct processing. RFC2518 weighs in much more positively about the trailling slash in section 5.2 with this little stanza (I recommend reading the whole section): There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names. I believe that this describes the exact behaviour of Apple's server, and Evolution should not be arbitrarily trifling with the URLs people give it (and don't get me started on the whole "caldav://" thing :-) Regards, Andrew McMillan.
Created attachment 123360 [details] [review] proposed eds patch for evolution-data-server; In code before the patch the trailing slash has been always removed from the user's uri. It's always appended after the patch.
Committed to trunk. Committed revision 9782.