Re: webDAV/CalDAV client class experience ?

On 13/02/13 14:27, Daniel Brown wrote:

On Tue, Feb 12, 2013 at 3:40 PM, B. Aerts <ba_aerts@yahoo.com> wrote:

Hello, I'm working on this one for more than a year (personal project) - but I'm turning pretty desperate here. I'm trying to connect to 2 Calendars through the CalDAV protocol. The calendars are hosted by 2 webmail providers. If I try to sync through a dedicated calendar, like iCal or Thunderbird Lightning add-on, this works fine. However, once I try to do it through "native" PHP, I fail miserably - even if I mimick HTTP requests as recorded by Charles (HTTP debugging proxy). Up until now, I used the inc_caldav-client-v2.php, which worked for a while and then stopped all of a sudden. The PUT requests failed, and then any HTTP request got caught in what appears to be a socket timeout. My question: is anyone using some webDAV/CalDAV class that actually works ? If not, any tutorial on the subject is also deeply appreciated ( all I can rely on is the IETF spec rfc4791, which is far from accesible reading material)

     I haven't tried them myself, but there are PEAR packages for

client-server implementations for WebDAV:

         http://pear.php.net/search.php?q=webdav&in=packages&x=0&y=0

     They're not actively maintained by anyone right now (feel free to

apply to change that if you'd like the responsibility), but the most recent server version was released just this past October (the client version is about a year older). At the very least, it may be enough to get you started.

Hello, I did try to download the PEAR package, but got stuck in some missing header problem. In the mean time however, I did manage to solve a few problems - listed for archiving's sake : - the biggest mistake: apparently I commented the fwrite() call to the stream, which explains why he went in time-out ... (in this case, please DO shoot the pianist) - CalDAVClient class from inc_caldav-client-v2.php always adds the port to the "Host" HTTP header, even if it is the default port; by removing it from the header, I got less problems - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g. GET, PROPFIND, REPORT) worked perfectly Only problem remaining was that PUT still isn't possible - at least not with one of the providers. Since I used a verbatim copy of a PUT action from the RFC, I strongly suspect the problem to be with the provider. Thanks for the help ! Bert