From: Leigh B. <le...@co...> - 2009-06-26 08:37:00
|
Hi, Thanks for your help. The database update script ran fine after I upgraded to postgresql 8.1 I ran the sql commands and unfortunately didnt see any report requests. Where do I enable the logs? Regards Leigh Andrew McMillan wrote: > 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 > ------------------------------------------------------------------------ > > -- Leigh Blackwell Coda Commerce Ltd Tel: 0845 8695884 le...@co... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |