andrew at morphoss
Jul 18, 2012, 9:32 PM
Post #2 of 6
(412 views)
Permalink
|
On Wed, 2012-07-18 at 18:15 +0200, Marc Patermann wrote:
> Hi,
>
> I connected an iPhone successfully to Davical 1.0.2 with CardDAV.
> Now I tried with Thunderbird 10 ESR, Lightning and SOGo Connector.
>
> On Thunderbird startup there is a connection to davical which is
> responded to with 207:
Yes. "207 multistatus" is the normal response code to a PROPFIND or
REPORT request (and some others also). In fact if you see a 200
response to one of these it indicates something has gone wrong.
>
> 192.168.178.20 - - [18/Jul/2012:17:31:42 +0200] "PROPFIND /davical/caldav.php/testuser.1 [at] fa-test1/addresses/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 Lightning/1.2.1"
> 192.168.178.20 - testuser.1 [at] fa-test1 [18/Jul/2012:17:31:58 +0200] "PROPFIND /davical/caldav.php/testuser.1 [at] fa-test1/addresses/ HTTP/1.1" 207 435 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 Lightning/1.2.1"
>
> Here is the davical log:
>
> [Wed Jul 18 17:31:58 2012] [error] [client 192.168.178.20] davical: LOG:
> :Response status 207 for PROPFIND
> /davical/caldav.php/testuser.1 [at] fa-test1/addresses/
> [Wed Jul 18 17:31:58 2012] [error] [client 192.168.178.20] davical: LOG:
> :***************** Response Header ****************
> headers:-->X-Powered-By: PHP/5.2.6
> headers:-->Server: 1.1
> headers:-->DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
> headers:-->DAV: extended-mkcol, bind, addressbook, calendar-proxy
> headers:-->ETag: "8f84b9690ca34fbfcecd9c394e4d9d65"
> headers:-->X-DAViCal-Version: DAViCal/1.1.0; DB/1.2.11
> headers:-->Content-type: text/xml; charset="utf-8"
> :******************** Response ********************
> response:--><?xml version="1.0" encoding="utf-8" ?>
> response:--><multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav" xmlns:C1="http://calendarserver.org/ns/">
> response:--> <response>
> response:--> <href>/davical/caldav.php/testuser.1%40fa-test1.foo/addresses/</href>
> response:--> <propstat>
> response:--> <prop>
> response:--> <resourcetype>
> response:--> <collection/>
> response:--> <C:addressbook/>
> response:--> </resourcetype>
> response:--> <supported-report-set>
> response:--> <supported-report>
> response:--> <report>
> response:--> <principal-property-search/>
> response:--> </report>
> response:--> </supported-report>
> response:--> <supported-report>
> response:--> <report>
> response:--> <principal-search-property-set/>
> response:--> </report>
> response:--> </supported-report>
> response:--> <supported-report>
> response:--> <report>
> response:--> <expand-property/>
> response:--> </report>
> response:--> </supported-report>
> response:--> <supported-report>
> response:--> <report>
> response:--> <sync-collection/>
> response:--> </report>
> response:--> </supported-report>
> response:--> <supported-report>
> response:--> <report>
> response:--> <C:addressbook-query/>
> response:--> </report>
> response:--> </supported-report>
> response:--> <supported-report>
> response:--> <report>
> response:--> <C:addressbook-multiget/>
> response:--> </report>
> response:--> </supported-report>
> response:--> </supported-report-set>
> response:--> <C1:getctag>"140006c70b309a14f4c9a1fb7f3d8eb4"</C1:getctag>
> response:--> </prop>
> response:--> <status>HTTP/1.1 200 OK</status>
> response:--> </propstat>
> response:--> </response>
> response:--></multistatus>
> response:-->
>
> So I think there is simply no real address data in the respond at all.
There was not any address data requested, although in any case address
data will never be returned in response to a PROPFIND request, but this
PROPFIND request was clearly sent with a "Depth: 0" header, in order to
retrieve collection properties, rather than the properties of resources
within the collection.
In particular the value of 'getctag' has been requested, which is an
opaque token which will change when the content of the collection
changes. Quite likely a previous request has fetched the collection
contents (probably a report) and this request is just checking that
nothing has changed.
> What is wrong here?
None of the above.
Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Flexibility is overrated. Constraints are liberating.
------------------------------------------------------------------------
|
signature.asc
