[CalendarServer-dev] Handling of URL encoding in server responses.

Peter Mogensen apm at one.com
Wed Aug 10 00:41:29 PDT 2016


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 at 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 at 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


More information about the calendarserver-dev mailing list