Запрос CalDAV на gGt События календаря iCloud

Я пытаюсь создать HTTP-запрос для получения событий из календаря iCloud. Я могу получить сведения о календаре (через PROPFIND) и получить сведения об отдельном событии календаря с помощью его идентификатора события (GET), но не могу написать запрос, который возвращает события календаря в пределах указанного диапазона времени.

Может ли кто-нибудь увидеть, что я делаю неправильно в приведенном ниже коде? Единственный ответ, который я получаю, это (код 207). В календаре есть одно событие в пределах установленного периода времени.

<multistatus xmlns="DAV:"/>

Из:

REPORT /<ICLOUD_USER_ID>/calendars/<ICLOUD_CALENDAR_ID>/ HTTP/1.1
Authorization: Basic <AUTHDATA>
Depth: 2
Prefer: return-minimal
Host: p31-caldav.icloud.com
Connection: close
User-Agent: Paw/2.2.2 (Macintosh; OS X/10.11.2) GCDHTTPRequest
Content-Length: 367

<c:calendar-query xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">      
    <d:prop>
        <c:calendar-data />
    </d:prop>
    <c:filter>        
        <c:comp-filter name="VCALENDAR">
            <c:comp-filter name="VEVENT">
                <c:time-range start="20160524T000000Z" end="20160526T000000Z" />
            </c:comp-filter>
        </c:comp-filter>
     </c:filter>
</c:calendar-query>

Заранее спасибо,

Джейми

Изменить: запрос на получение, который работает:

Запрос:

GET /<ICLOUD_USER_ID>/calendars/<ICLOUD_CALENDAR_ID>/<ICLOUD_EVENT_ID>.ics HTTP/1.1
Authorization: Basic <AUTHDATA>
Depth: 1
Prefer: return-minimal
Host: p31-caldav.icloud.com
Connection: close
User-Agent: Paw/2.2.2 (Macintosh; OS X/10.11.2) GCDHTTPRequest

Ответ:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.11.2//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Australia/Sydney
X-LIC-LOCATION:Australia/Sydney
BEGIN:STANDARD
DTSTART:18950201T000000
RDATE;VALUE=DATE-TIME:18950201T000000
TZNAME:AEST
TZOFFSETFROM:+100452
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19170101T000100
RDATE;VALUE=DATE-TIME:19170101T000100
RDATE;VALUE=DATE-TIME:19420101T020000
RDATE;VALUE=DATE-TIME:19420927T020000
RDATE;VALUE=DATE-TIME:19431003T020000
RDATE;VALUE=DATE-TIME:19861019T020000
RDATE;VALUE=DATE-TIME:20000827T020000
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19170325T020000
RDATE;VALUE=DATE-TIME:19170325T020000
RDATE;VALUE=DATE-TIME:19420329T020000
RDATE;VALUE=DATE-TIME:19720227T030000
RDATE;VALUE=DATE-TIME:19820404T030000
RDATE;VALUE=DATE-TIME:20060402T030000
RDATE;VALUE=DATE-TIME:20070325T030000
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:19430328T020000
RRULE:FREQ=YEARLY;UNTIL=19440325T150000Z;BYDAY=-1SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:19710101T000000
RDATE;VALUE=DATE-TIME:19710101T000000
TZNAME:AEST
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19711031T020000
RRULE:FREQ=YEARLY;UNTIL=19851026T160000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19730304T030000
RRULE:FREQ=YEARLY;UNTIL=19810228T160000Z;BYDAY=1SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:19830306T030000
RRULE:FREQ=YEARLY;UNTIL=19850302T160000Z;BYDAY=1SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:19860316T030000
RRULE:FREQ=YEARLY;UNTIL=19890318T160000Z;BYDAY=3SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19871025T020000
RRULE:FREQ=YEARLY;UNTIL=19991030T160000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19900304T030000
RRULE:FREQ=YEARLY;UNTIL=19950304T160000Z;BYDAY=1SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:19960331T030000
RRULE:FREQ=YEARLY;UNTIL=20050326T160000Z;BYDAY=-1SU;BYMONTH=3
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20011028T020000
RRULE:FREQ=YEARLY;UNTIL=20071027T160000Z;BYDAY=-1SU;BYMONTH=10
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20080406T030000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20081005T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=10
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20160331T004928Z
UID:86ABADB9-CDC3-45D0-B932-5420DC10390A
DTEND;TZID=Australia/Sydney:20160425T093000
SUMMARY:Sample Event
DTSTART;TZID=Australia/Sydney:20160425T073000
DTSTAMP:20160509T000541Z
LAST-MODIFIED:20160408T220749Z
SEQUENCE:1
TRANSP:OPAQUE
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
END:VEVENT
END:VCALENDAR

calendar icalendar caldav webdav
person Jamie    schedule 08.05.2016    source источник
comment
Можете ли вы добавить iCalendar события? Вы уверены, что запрашиваете правильный календарь?   -  person hnh    schedule 08.05.2016
comment
Уверен, что я нахожусь в правильном календаре, поскольку я могу получить одно событие из этого календаря с помощью запроса GET; это просто запросы REPORT, которые, кажется, не работают для меня   -  person Jamie    schedule 08.05.2016
comment
Добавьте iCalendar, возвращенный GET, в свой Q   -  person hnh    schedule 08.05.2016
comment
Я добавил его - идентификатор события исходит из экспорта файла ics из приложения OS X Calendar, затем чтения его идентификатора и добавления его в запрос   -  person Jamie    schedule 09.05.2016
comment
Как это выглядит необычно - просто для уверенности, вы действительно запрашиваете два дня, а не один, с 24.05 по 26.05? Потому что ваше событие 4/25 на самом деле является 4/24 в UTC...   -  person hnh    schedule 09.05.2016
comment
Правильный; Я сужу его позже; здесь я просто гарантирую, что зафиксирую созданное мной Sample Event   -  person Jamie    schedule 09.05.2016
comment
Сравнивая ваш запрос с тем, что отправляет Calendar.app, вам не хватает пары заголовков HTTP. Может потребоваться Content-Type: text/xml. И вам не хватает объявления xml в начале полезной нагрузки XML (‹?xml version=1.0 encoding=UTF-8?›).   -  person diciu    schedule 10.05.2016
comment
@Jamie Ты когда-нибудь решал эту проблему? Несколько недель назад у меня была работающая система, и теперь (без каких-либо изменений на стороне клиента) я получаю тот же ответ, в то время как изменения PUT и отдельные события GET по-прежнему работают нормально.   -  person Nicolas    schedule 09.09.2019

Ответы (4)


arrow_upward
1
arrow_downward

Нет такой вещи, как Depth: 2. Вы, вероятно, хотите Depth: 1.

Проверьте: RFC2518

person hnh    schedule 08.05.2016
comment
Изменено на глубину 1, результат не изменился, но все равно спасибо, что заметили - person Jamie; 08.05.2016

arrow_upward
1
arrow_downward

Речь идет о реализации поставщика календаря. С телом запроса все в порядке, и, увидев представление iCalendar события, ответ на запрос должен вернуть событие.

Единственное, что я вижу, что может быть причиной этого, это заголовок Prefer: return-minimal. См. Предпочтение "return-minimal" чтобы узнать больше об этом. calendar-query REPORT запрашивает только calendar-data. Обычно клиент запрашивает eTags, поэтому он проверяет, есть ли какая-либо разница между объектом календаря, который у него есть, и объектом на сервере, если есть какой-либо другой объект календаря, тогда клиент отправляет CALDAV:calendar-multiget REPORT с href объектов календаря, которые разные.

Попробуйте удалить заголовок Prefer: return-minimal или вместо этого попробуйте изменить

<d:prop>
    <c:calendar-data />
</d:prop>

to 

<d:prop>
    <d:getetag />
</d:prop>

Надеюсь, поможет.

person wajiro_91    schedule 09.05.2016
comment
То, что минимальный возврат является причиной, довольно маловероятно, но просто запрос etag - очень хорошее предложение. Вполне возможно, что сервер поддерживает только подмножество свойств для запроса временного диапазона. - person hnh; 09.05.2016
comment
Я знаю, что это маловероятно, но использование этого заголовка для запроса calendar-data не имеет смысла, потому что ответ на это совсем не будет минимальным. Вот почему я думаю, что он должен либо удалить заголовок, либо запросить calendar-data, либо запросить eTags с тем же заголовком. - person wajiro_91; 09.05.2016
comment
Также нет смысла указывать заголовок для getetag, так как это свойство существует всегда. Это в основном полезно для коллекции календарей, поскольку они имеют менее однородные свойства. - person hnh; 09.05.2016

arrow_upward
0
arrow_downward

Как было предложено, попробуйте запросить только тег etag, а затем используйте URL-адреса с ответами для ОТЧЕТА по календарю-мультиполучению.

Я могу порекомендовать вам использовать fiddler или любую другую программу, чтобы вы могли четко видеть запросы и ответы. Также попробуйте посмотреть запросы от других клиентов, таких как emClient, например.

person Richard Loth    schedule 01.06.2016

arrow_upward
0
arrow_downward 

Method-: REPORT
Content type-: application/xml; charset=utf-8
Header -: Depth : 1
URL-:GET /<ICLOUD_USER_ID>/calendars/
Set credentials
Following is RequestContent-:
<C:calendar-query xmlns:D='DAV:'
                 xmlns:C='urn:ietf:params:xml:ns:caldav'>
                                     <D:prop>
                                       <D:getetag/>
                                       <C:calendar-data>
                                         <C:comp name='VCALENDAR'>
                                           <C:prop name='VERSION'/>
                                           <C:comp name='VEVENT'>
                                             <C:prop name='SUMMARY'/>
                                             <C:prop name='DESCRIPTION'/>
                                             <C:prop name='STATUS'/>
                                              <C:prop name='TRANSP'/>
                                               <C:prop name='ATTENDEE'/>
                                             <C:prop name='UID'/>
                                             <C:prop name='DTSTART'/>
                                             <C:prop name='DTEND'/>
                                             <C:prop name='DURATION'/>
                                             <C:prop name='RRULE'/>
                                             <C:prop name='RDATE'/>
                                             <C:prop name='EXRULE'/>
                                             <C:prop name='EXDATE'/>
                                             <C:prop name='RECURRENCE-ID'/>
                                           </C:comp>
                                         </C:comp>
                                       </C:calendar-data>
                                     </D:prop>
                                     <C:filter>
       <C:comp-filter name='VCALENDAR'>
         <C:comp-filter name='VEVENT'>
           <C:time-range start='20160524T000000Z'
                         end='20160526T000000Z'/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
                                   </C:calendar-query>

Я думаю, что проблема связана с URL-адресом и используемым методом. Используйте URL-адрес для календарей, т.е. /ICLOUD_USER_ID/calendars/, и метод должен быть REPORT.

person Priyank Kotiyal    schedule 06.03.2017