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 <awilliam@xxxxxxxxxxxxx> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
