calendarserver-dev

Download

calendarserver-dev@lists.macosforge.org

August 2016

3 participants
2 discussions

CalendarServer has moved to github
by Cyrus Daboo 15 Aug '16

15 Aug '16

Hi folks, The CalendarServer project (and associated dependent projects) have all been moved from the MacOSForge hosted subversion server to github. The calendarserver.org domain will continue to work and serve up the new github-based content. Just visit <https://www.calendarserver.org> to see the new instructions for getting access to code. These mailing lists will continue to work. For issues, please use the github issue tracker for ccs-calendarserver: <https://github.com/apple/ccs-calendarserver/issues>. If you do any code changes yourself, please create pull requests to have those integrated into the main repository if needed. -- Cyrus Daboo

2 4

Handling of URL encoding in server responses.
by Peter Mogensen 10 Aug '16

10 Aug '16

Hi, I'm looking at a strange little scenario with a client trying to sync with the CalendarServer. It goes like this, in summary: C: REPORT:calendar-query /calendars/users/me@domain/calendar/ ---------------------------------------------------------------- <?xml version="1.0"?> <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop xmlns:D="DAV:"> <D:getetag/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"> <C:comp-filter name="VEVENT"> <C:time-range start="20160611T000000Z" end="20170207T000000Z"/> </C:comp-filter> </C:comp-filter> </C:filter> </C:calendar-query> ----------------------------------------------------------------- S: 207 - Here's a bunch of hrefs of the form: <href>/calendars/users/me%40domain/calendar/blabla.ics</href> C: REPORT:calendar-multiget /calendars/users/me@domain/calendar/ <href>/calendars/users/me%40domain/calendar/blabla.ics</href ... ================================================================= Now ... it's clear from https://tools.ietf.org/html/rfc4918#section-8.3 that the last request is illegal. Or rather... if one parses the URL comparison rules it seems to say that the Request-URI and the <href> should be octet-by-octet compared, so "@" != "%40" here. However... (and this is the question) ... I'm a little in doubt about how to interpret RFC4918, section 8.3 wrt. which rules the server should obey wrt. the Request-URI when formulating the response. Is the server allowed to respond with <href>/%40</href> when the Request-URI was /@ ? regards, Peter Mogensen

2 4