Re: [DAViCal-general] iphone 3.0

[Andrew M. <an...@mo...>]

On Fri, 2009-06-26 at 00:01 +0100, Leigh Blackwell wrote:
> Hi,
> 
> I have installed the lastest debian packages and have the davical 
> running on thunderbird without any problems. I have tried to use it on 
> the iphone and can report similar issues to others on this list. I can 
> add an account and have it verified, but when you can create an event it 
> is transfered to the server and therefore appears in the thunderbird 
> client. However the no events are downloaded to the iphone.
> 
> I  have looked at my apache logs and can see the fact information is 
> being requested. However where thunderbird does this in two requests  to 
> one URL to "PROPFIND /caldav.php/username/home/" then followed by a 
> "REPORT /caldav.php/username/home/". The iphone goes to
> "PROPFIND /caldav.php/username/" then followed by   "PROPFIND 
> /caldav.php/username/home/" the second request is when the mass of data 
> is returned; by this looks of it that is being ignored. This seems to be 
> a result of the iphone refusing to accept the trailing "/" when saving 
> the location.

No, that isn't the problem.  The PROPFIND request which the iPhone does
are not particularly unusual, and the process of PROPFIND, REPORT is not
comparable to Lightning - there are many ways to do it, and the two have
chosen similar but not identical approaches.


> As a hack could we allow a default name i.e. "/username/home/__iphone" 
> to be placed after the trailing / which could be stripped out before 
> being processed to see if this is the cause of the problem.

The iPhone strips the trailling '/' when you create the URL, but you'll
note that it puts a trailling '/' on when it requests against the
server.  In any case DAViCal already has a mechnism to handle requests
which do not have the trailling '/'.

The first PROPFIND that the iPhone does requests a variety of properties
related to the principal, in particular the calendar-home-set property.
Subsequent PROPFIND tend to be Depth: 1.

In my own case, I can see the following log of requests from my iPhone:

PROPFIND /username/
PROPFIND /username/
PROPFIND /username/home/

When there is new data to be fetched, this will be followed by:

REPORT /username/home/

And, of course, sometimes you may see:

PUT /username/home/longstringofdigits.ics

when a new event is added,
or:

DELETE /username/home/longstringofdigits.ics

when an event is deleted


This is with the URL in the calendar configured as just
'https://host.domain.com:8443/caldav.php/username/'

(I'm running my server using SSL on port 8443)

Note that the URL I have entered into the iPhone *does* *not* include
the '/home/' on the end, which is different to the URL used for
Lightning / Sunbird / Evolution, and several others, because the iPhone
will discover the calendar for itself, from the Principal properties. In
this it is the same as iCal, though it also differs from iCal in some
respects.

The access logs contain *very* limited information, since they do not
introspect the contents of the PROPFIND or REPORT request, both of which
are XML documents capable of varying the result enormously.

If you never see a 'REPORT' request, however, the iPhone is not getting
anything.  Did you definitely run the database upgrade script, and did
it work when you did?

You could try this little bit of SQL to change all the collection &
entry etags, and you should see a subsequent flurry of REPORT activity
(1 per calendar) as the iPhone downloads everything again, thinking it
has all changed...

BEGIN;
UPDATE collection SET dav_etag = md5(random()::text);
UPDATE caldav_data SET dav_etag = md5(random()::text);
COMMIT;

This will change the 'etag' for everything in the database, which is
what is held by the client to compare against to see if an item has
changed, so when it does it's next PROPFIND it will see the changed etag
and (theoretically) request the event again.

If you *don't* see a REPORT in your access log after doing that (and
hopefully some events in your iPhone) then something very peculiar is
happening, and seeing a full log of the several subsequent
requests/responses with full debugging enabled would be very useful.

Cheers,
					Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
                Necessity is the mother of documentation
------------------------------------------------------------------------