Menu
▾
▴
davical-general
|
From: Leigh B. <le...@co...> - 2009-06-25 23:27:52
|
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. 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. Regards Leigh -- 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. |
|
From: Andrew M. <an...@mo...> - 2009-06-26 01:19:50
|
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 ------------------------------------------------------------------------ |
|
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. |
|
From: Leigh B. <le...@co...> - 2009-06-26 11:18:30
|
I tried a fresh install this time making sure nothing went wrong the database install scripts, I firstly did a dist-upgrade on lenny and also installed postgressql 8.3. The results are the same a working admin gui and calendar in thunderbird but no downloading of events on to the iphone 3gs (3.0 7A341) and also the DELETE request doesn't take place even after a successful PUT. Thanks Leigh Leigh Blackwell wrote: > 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: 01784 256896 Fax: 01784 249120 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Leigh B. <le...@co...> - 2009-06-26 14:12:55
|
Looks like we have success I had two handset identically set-up and on my handset the sync option was set to "all events" and wasn't showing anything; however when I got the other phone I was surprised to find that it had listings which I imagine was a result of the re-install on 8.3 as it wasn't working before. The second handset was on the default 1 month sync. Many thanks for your help, I will let you know if we find any unexpected iphone features :) Regards Leigh Andrew McMillan wrote: > On Fri, 2009-06-26 at 09:05 +0100, Leigh Blackwell wrote: > >> 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. >> > > Urk! Sorry - I hadn't realised you were on an older version of > PostgreSQL. I have not tested 0.9.7 anything on < 8.1 > > > >> Where do I enable the logs? >> > > Add this line to your DAViCal configuration file: > > $c->dbg['ALL'] = 1; > > With 0.9.7 these logs include the full request/response, so there is no > need for tcpdump or similar, and it will also log everything if you're > using SSL. Of course this also means that all your passwords etc. are > in there, so you'll probably want to obscure those, and/or not send it > to the list... > > Cheers, > Andrew. > > ------------------------------------------------------------------------ > http://andrew.mcmillan.net.nz/ Porirua, New Zealand > Twitter: _karora Phone: +64(272)DEBIAN > Don't feed the bats tonight. > ------------------------------------------------------------------------ > > -- *Leigh Blackwell* Coda Commerce Ltd Tel: 01784 256896 Fax: 01784 249120 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Andrew M. <an...@mc...> - 2009-06-26 23:20:01
|
On Fri, 2009-06-26 at 14:17 +0100, Leigh Blackwell wrote: > Looks like we have success I had two handset identically set-up and on > my handset the sync option was set to "all events" and wasn't showing > anything; however when I got the other phone I was surprised to find > that it had listings which I imagine was a result of the re-install on > 8.3 as it wasn't working before. The second handset was on the default > 1 month sync. > > Many thanks for your help, I will let you know if we find any > unexpected iphone features :) It seems that this is not an uncommon problem, and it would be good to know whether the longer sync is running out of memory in DAViCal, or if it is a problem on the iPhone itself. Any chance of reviewing the differences in behaviour between the two, and helping identify where the problem is? Thanks, Andrew. ------------------------------------------------------------------------ http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN An exotic journey in downtown Newark is in your future. ------------------------------------------------------------------------ |
Thanks for helping keep SourceForge clean.
X