[cosmo-dev] RFC4791 HTTP REPORT and Cosmo

[Grant Baillie]

Hi, Sam

It's been a while since I looked at the details of CalDAV, but if I  
remember right:

- The calendar-home-set REPORT you tried (which worked) pointed you  
at /webcal/dav/samuel/ as the "home directory" for CalDAV calendars on  
the server, as it is supposed to.

- The top-level collection on Cosmo (/webcal/dav/myusername/ for you)  
is an ordinary WebDAV collection, not a calendar. So, when you did a  
Depth: 0 calendar-query REPORT on it, the server replied with a "this  
isn't a calendar" response. To get actual calendar data, pass in a non- 
zero Depth (I'm not sure if Depth: infinity is supported, though).  
Alternatively, you can use standard WebDAV PROPFIND requests to find  
where the individual calendars are beneath that top-level collection,  
and query those.


Hope this helps,
--Grant

On 17 Aug, 2008, at 06:32, Sam Halliday wrote:

> Hi all,
>
> Frustrated with the lack of open standards on my new HTC Touch  
> Diamond mobile phone (which runs Windows Mobile 6.1) and the  
> complete lack of usability of the PIM software, I am embarking on  
> the mission of creating a CalDAV-aware J2ME client that will focus  
> entirely on Tasks (VTODO items) from a CalDAV server. I was shocked  
> to discover that nobody has yet written a CalDAV-aware mobile client!
>
> I've been reading up on CalDAV at http://tools.ietf.org/html/rfc4791  
> and am somewhat annoyed that almost everything uses HTTP REPORT,  
> which of course is not supported by any of the Java Connection  
> libraries and it means going back to basics with raw HTTP access  
> over a socket (oh joy!). I don't see why they didn't just use POST...
>
> I have been able to successfully work out how to do BASIC  
> authentication over HTTP and am able to send some of the example  
> requests in the RFC to Cosmo. However, I am getting errors on these  
> textbook requests. I have Cosmo installed at the Context "/webcal/"  
> and when I send the request (which is straight from http://tools.ietf.org/html/rfc4791#section-7.8.9 
>  to retrieve all pending VTODO items)
>
> =========================================
> REPORT /webcal/dav/users/myusername/ HTTP/1.1
> Authorization: Basic mybase64usernamepasswordpair
> Host: myhost.com
> Content-Type: text/xml;charset=UTF-8
> Depth: 0
> Content-Length: 463
>
> <?xml version="1.0" encoding="utf-8"?><C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav 
> "><D:prop xmlns:D="DAV:"><D:getetag/><C:calendar-data/></ 
> D:prop><C:filter><C:comp-filter name="VCALENDAR"><C:comp-filter  
> name="VTODO"><C:prop-filter name="COMPLETED"><C:is-not-defined/></ 
> C:prop-filter><C:prop-filter name="STATUS"><C:text-match negate- 
> condition="yes">CANCELLED</C:text-match></C:prop-filter></C:comp- 
> filter></C:comp-filter></C:filter></C:calendar-query>
> =========================================
> I get the response
> =========================================
> <?xml version='1.0' encoding='UTF-8'?><D:error xmlns:D="DAV:"  
> xmlns:cosmo="http://osafoundation.org/cosmo/ 
> DAV"><cosmo:unprocessable-entity>Unknown report {urn:ietf:params:xml:ns:caldav 
> }calendar-query</cosmo:unprocessable-entity></D:error>
> =========================================
>
> I've tried with different paths, including "/webcal/dav/myusername",  
> but to no avail. If I use GET, on these URLs, then I do get sensible  
> HTML responses... but as far as I am aware, that is not a part of  
> the CalDAV specification! (It certainly doesn't result in a response  
> from Google Calendar which is an independent implementation).
>
> I get similar responses for every single example that I have tried  
> from the RFC, the only request that has resulted in a sensible  
> response has been
> =========================================
> REPORT /webcal/dav/users/samuel/ HTTP/1.1
> Authorization: Basic mybase64usernamepasswordpair
> Host: myhost.com
> Content-Type: text/xml;charset=UTF-8
> Depth: 0
> Content-Length: 180
>
> <?xml version="1.0" encoding="utf-8"?><D:principal-match  
> xmlns:D="DAV:"><D:self/><D:prop><C:calendar-home-set xmlns:C="urn:ietf:params:xml:ns:caldav 
> "/></D:prop></D:principal-match>
> =========================================
> With response
> =========================================
> <?xml version="1.0" encoding="UTF-8"?>
> <D:multistatus xmlns:D="DAV:">
>    <D:response>
>        <D:href>/webcal/dav/users/samuel</D:href>
>        <D:propstat>
>            <D:prop>
>                <C:calendar-home-set xmlns:C="urn:ietf:params:xml:ns:caldav 
> ">
>                    <D:href>/webcal/dav/samuel/</D:href>
>                </C:calendar-home-set>
>            </D:prop>
>            <D:status>HTTP/1.1 200 OK</D:status>
>        </D:propstat>
>    </D:response>
> </D:multistatus>
> =========================================
> But when I do that request on Google Calendar, I get a "Method Not  
> Allowed" error! Is it possible that Google have decided to scrap the  
> HTTP REPORT method in preference of something more sane (but non- 
> compliant)?
>
> My goal is to be able to provide CalDAV read and write access to  
> VTODO items... therefore I would require the following:-
>
> - given a valid CalDAV URL, find the user's collections (and the  
> base URLs for making the following requests)
> - CRUD on VTODO items in all user's collections (and for specified  
> collections)
>
> does anybody here have any advice on the best way to do this? If  
> there is a way to avoid having to use HTTP REPORT, I'm all ears (but  
> please stick to the RFC, I don't want to lock this to Cosmo).
>
> Incidentally, where is the DTD for the "DAV" and "urn:ietf:params:xml:ns:caldav 
> " namespaces? Note also that http://osafoundation.org/cosmo/DAV  
> doesn't exist anymore!
>
> -- 
> Sam
>
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev