Re: [PHP] webDAV/CalDAV client class experience ?

On Mon, 2013-02-18 at 12:19 +0100, B. Aerts wrote:
> >> - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g.
> >> GET, PROPFIND, REPORT) worked perfectly
> >
> > This is interesting. The Accept header has to do with what media types
> > the browser will accept in return. I didn't think it had anything to
> > do with what operations the server/application accepts. Must go read
> > further....
> 
> I'll have to revoke this statement, as I can't reproduce it anymore.
> I noticed the DaviCal didn't use it, bu the CURL call did - and yielded 
> more ( = meaningfull) results.
> But, as I said, can't reproduce it.
> 
> The thing I could reproduce was that, if the request was sent to the 
> default port, AND this port was included in the "Host" header, both GET 
> and PUT yielded HTTP 404.
> 
> >
> >> 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.
> >
> > You've no doubt considered this already, but it might be intentional
> > on the provider's part. I'm not up on all the webDAV/calDAV providers;
> > I imagine some of them might add in additional layers of auth
> > (including the NOWAI layer)  just to consider themselves more secure.
> >
> Yes I did, but the following arguments should negate that consideration:
> - when running OPTIONS, PUT is included in the allowed HTTP methods
> - the HTTP return code from the PUT command is 301, where a security 
> issue would have yielded a code in the 400 range

Ok, and the 301 response contains a Location: header?  A 301 as a
response to PUT just means the server relocated/renamed the resource. 

> - the other provider does respond as expected (though I agree, that is 
> the weakest argument: expectations != specifications )

Nobody, nowhere, matches the spec.

> - the provider does allow sync'ing Sunbird, iCal, ... over CalDAV, and 
> that works, even entering a new event (which is a PUT action). The 
> Charles debugging proxy too shows that it's only Basic authentication 
> that's going up - and succeeding

If your response is 301 why do you believe it is failing?

> $body = <<<XML
> <?xml version="1.0" encoding="utf-8" ?>
> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
>       <D:prop>
>         <C:calendar-data/>
>         <D:getetag/>
>       </D:prop>
>       <C:filter>
>         <C:comp-filter name="VCALENDAR">
>           <C:comp-filter name="VEVENT">
>             <C:time-range start="20130201T000001Z" end="20130228T000001Z"/>
>           </C:comp-filter>
>         </C:comp-filter>
>       </C:filter>
> </C:calendar-query>

Does PHP provide some kind of XML building library?  String building XML
is *always* dicey and it is *VERY* easy to introduce encoding problems.
Something at least with an codepage codec would be good.  [although it
*should* work, I manipulate WebDAV servers via curl CLI all the time].

In Python a combination of ElementFlow and the codecs module is
perfection.  I assume there is a PHP equivalent.

-- 
Adam Tauno Williams <[email protected]>