Fw: [CalendarServer-dev] Bug related to Example 7.8.6 in the RFC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, should have been to the list. Begin forwarded message: Date: Fri, 4 Apr 2008 15:52:34 +0200 From: Michael Rasmussen <mir@datanom.net> To: Helge Heß <me@helgehess.eu> Subject: Re: [CalendarServer-dev] Bug related to Example 7.8.6 in the RFC - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Helge, On Fri, 4 Apr 2008 01:53:12 +0200 Helge Heß <me@helgehess.eu> wrote:
I have the impression that you use the term 'collection' a bit inappropriately.
Well, collection was used as an "abstract class":-)
A (WebDAV) 'collection' does not have an etag (it can have a ctag, but thats Apple specific, not CalDAV). It can also have an ics resource representation which then can have an etag (when you query it using GET, but this is not really CalDAV or collection related).
I no. The main idea is this: 1) I want to be able to retrieve any resource related to a specific ACL for the shake of been able to share calendar resources in a generic way. 2) A VEVENT is not required to store information about its specific ICal resource, but following the CalDAV specification any VEVENT is required to store its UID which must be unique. 3) Having a specific VEVENT means access to its unique UID by which it is possible to get the associated ETag with this specific iCal resource. 4) According to the CalDAV specification the ETag is required to be able to modify and/or delete an iCal resource.
Just use <C:text-match>20080404t182145z-123401@example.com</C:text-match> for now (per spec this will default to "i;ascii-casemap").
Yes, of course:-) Thanks.
I guess this didn't come up before because clients usually query servers by URL, not by UID. Which I personally prefer anyways (why do you use the UID in the first place?).
As explained above. You cannot be certain that you know the URL. Many clients store the specific resource name and combining this with the URL to the collection, you have the URL. You can be certain that you know the UID since by specification any resource must save it in a guarantied unique manor. - - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - - -------------------------------------------------------------- Debian Hint #7: You can use the cron-apt package to do automatic nightly downloads of updates for packages installed on your system. - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9jKiQQOPluUB9RwRAidKAJ0Z1E9Xb7hPItn5UrsJgps4iQDnLQCfUHDs k65HMLzc1JDIEaU2VRHGUYs= =oMZV - -----END PGP SIGNATURE----- - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- Don't get to bragging. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9jbRQQOPluUB9RwRArTuAKCWr7dsroWAZ/XQ4yYBLqIlpkjKiACglvsx eB2FHcbGVJy8r92y2RRZzfU= =7E0U -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Apr 2008 16:10:25 +0200 Michael Rasmussen <mir@datanom.net> wrote:
Just use <C:text-match>20080404t182145z-123401@example.com</C:text-match> for now (per spec this will default to "i;ascii-casemap").
I have now tried the suggested solution but it does not seem to work. I get a code 207 <?xml version='1.0' encoding='UTF-8'?> <multistatus xmlns='DAV:'/>. An empty resultset. It appears to me that ICalendar simply silently ignores the request to do text-match or in some other way has a buggy search algorithm which always returns empty. I this a wrong interpretation? - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- Forrest Gump: "They sending me to Vietnam - it's this whole other country" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9neZQQOPluUB9RwRAo1CAJ4hEYOIHuZiDRgbZBDhSdsimlIRMgCfR9Nd 3WLtWJ6UIf/ppw4GOtlvqzc= =qlro -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Apr 2008 20:46:49 +0200 Michael Rasmussen <mir@datanom.net> wrote:
I have now tried the suggested solution but it does not seem to work. I get a code 207 <?xml version='1.0' encoding='UTF-8'?> <multistatus xmlns='DAV:'/>. An empty resultset. It appears to me that ICalendar simply silently ignores the request to do text-match or in some other way has a buggy search algorithm which always returns empty. I this a wrong interpretation?
It gets spooky now. Changing to search for SUMMARY and using some fraction of the stored text as search term gave a response! Is doing text-match search on property UID prohibited or does ICalendar expect it in an undocumented way? $ test/src/caldav-test -d -uadmin -padmin -a modify http://localhost:8008/calendars/users/admin/calendar/ < test/ics/modify.ics == Info: About to connect() to localhost port 8008 (#0) == Info: Trying 127.0.0.1... == Info: connected == Info: Connected to localhost (127.0.0.1) port 8008 (#0) == Info: Server auth using Basic with user 'admin' => Send header, 236 bytes (0xec) 0000: REPORT /calendars/users/admin/calendar/ HTTP/1.1 0032: Authorization: Basic YWRtaW46YWRtaW4= 0059: User-Agent: libcurl-agent/0.1 0078: Host: localhost:8008 008e: Accept: */* 009b: Content-Type: application/xml; charset="utf-8" 00cb: Depth: 1 00d5: Content-Length: 433 00ea: => Send data, 433 bytes (0x1b1) 0000: <?xml version="1.0" encoding="utf-8" ?><C:calendar-query xmlns:D 0040: ="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> < 0080: D:prop> <D:getetag/> <C:calendar-data/> </D:prop> <C:fil 00c0: ter> <C:comp-filter name="VCALENDAR"> <C:comp-filter nam 0100: e="VEVENT"> <C:prop-filter name="SUMMARY"> 0133: <C:text-match>Frodo</C:text-match> 0157: </C:prop-filter> </C:comp-filter> </C:comp-filter> </C: 0197: filter></C:calendar-query> <= Recv header, 27 bytes (0x1b) 0000: HTTP/1.1 207 Multi-Status <= Recv header, 21 bytes (0x15) 0000: Content-Length: 747 <= Recv header, 22 bytes (0x16) 0000: Accept-Ranges: bytes <= Recv header, 104 bytes (0x68) 0000: Server: Twisted/2.5.0+rUnknown TwistedWeb/[twisted.web2, version 0040: 0.2.0 (SVN rUnknown)] TwistedCalDAV/? <= Recv header, 46 bytes (0x2e) 0000: Last-Modified: Thu, 03 Apr 2008 10:16:09 GMT <= Recv header, 150 bytes (0x96) 0000: DAV: 1, access-control, calendar-access, calendar-schedule, cale 0040: ndar-availability, inbox-availability, calendar-proxy, calendars 0080: erver-private-events <= Recv header, 30 bytes (0x1e) 0000: ETag: "3C17D728-4C-47F4AE69" <= Recv header, 37 bytes (0x25) 0000: Date: Fri, 04 Apr 2008 18:50:55 GMT <= Recv header, 24 bytes (0x18) 0000: Content-Type: text/xml <= Recv header, 2 bytes (0x2) 0000: <= Recv data, 747 bytes (0x2eb) 0000: <?xml version='1.0' encoding='UTF-8'?> 0028: <multistatus xmlns='DAV:'> 0044: <response> 0052: <href>/calendars/users/admin/calendar/libcaldav-5081183482b5 0092: b610c7c8c4ffe84e0f72.ics</href> 00b3: <propstat> 00c3: <prop> 00d1: <getetag>"0bcef893f5022bf391b3707ef40ef6a6"</getetag> 0110: <calendar-data xmlns='urn:ietf:params:xml:ns:caldav'><![ 0150: CDATA[BEGIN:VCALENDAR 0167: VERSION:2.0 0174: PRODID:-//Example Corp.//CalDAV Client//EN 01a0: BEGIN:VEVENT 01ae: UID:20080404T182145Z-123401@example.com 01d7: DTSTART:20080415T151500Z 01f1: DTEND:20080415T162500Z 0209: DTSTAMP:20080404T182145Z 0223: SUMMARY:Frodo's birthday party. Please respond. 0254: END:VEVENT 0260: END:VCALENDAR 026f: ]]></calendar-data> 0284: </prop> 0293: <status>HTTP/1.1 200 OK</status> 02bb: </propstat> 02cc: </response> 02db: </multistatus> == Info: Connection #0 to host localhost left intact == Info: Re-using existing connection! (#0) with host localhost == Info: Connected to localhost (127.0.0.1) port 8008 (#0) == Info: Server auth using Basic with user 'admin' => Send header, 313 bytes (0x139) 0000: PUT /calendars/users/admin/calendar/libcaldav-5081183482b5b610c7 0040: c8c4ffe84e0f72.ics HTTP/1.1 005d: Authorization: Basic YWRtaW46YWRtaW4= 0084: User-Agent: libcurl-agent/0.1 00a3: Host: localhost:8008 00b9: Accept: */* 00c6: If-Match: "0bcef893f5022bf391b3707ef40ef6a6" 00f4: Content-Type: text/calendar; charset="utf-8" 0122: Content-Length: 271 0137: => Send data, 271 bytes (0x10f) 0000: BEGIN:VCALENDAR.VERSION:2.0.PRODID:-//Example Corp.//CalDAV Clie 0040: nt//EN.BEGIN:VEVENT.DTSTAMP:20080404T182145Z.DTSTART:20080416T15 0080: 1500Z.DTEND:20080416T162500Z.SUMMARY:Frodo's birthday party. Ple 00c0: ase respond..UID:20080404T182145Z-123401@example.com.END:VEVENT. 0100: END:VCALENDAR.. <= Recv header, 25 bytes (0x19) 0000: HTTP/1.1 204 No Content <= Recv header, 19 bytes (0x13) 0000: Content-Length: 0 <= Recv header, 104 bytes (0x68) 0000: Server: Twisted/2.5.0+rUnknown TwistedWeb/[twisted.web2, version 0040: 0.2.0 (SVN rUnknown)] TwistedCalDAV/? <= Recv header, 46 bytes (0x2e) 0000: Last-Modified: Fri, 04 Apr 2008 18:50:56 GMT <= Recv header, 150 bytes (0x96) 0000: DAV: 1, access-control, calendar-access, calendar-schedule, cale 0040: ndar-availability, inbox-availability, calendar-proxy, calendars 0080: erver-private-events <= Recv header, 42 bytes (0x2a) 0000: ETag: "cbdc6ba200c15f02f7bbe6d389b21ba4" <= Recv header, 37 bytes (0x25) 0000: Date: Fri, 04 Apr 2008 18:50:56 GMT <= Recv header, 2 bytes (0x2) 0000: == Info: Connection #0 to host localhost left intact == Info: Closing connection #0 empty collection OK - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- BOFH excuse #250: Program load too heavy for processor to lift. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9npEQQOPluUB9RwRAl1OAKCfKwfOOK/ruYutTAZBB0Chl5O4zACbBnCr NbEsjexs0Z4i+zw5HND2lC4= =nwgQ -----END PGP SIGNATURE-----
Hi Michael, --On April 4, 2008 8:58:12 PM +0200 Michael Rasmussen <mir@datanom.net> wrote:
I have now tried the suggested solution but it does not seem to work. I get a code 207 <?xml version='1.0' encoding='UTF-8'?> <multistatus xmlns='DAV:'/>. An empty resultset. It appears to me that ICalendar simply silently ignores the request to do text-match or in some other way has a buggy search algorithm which always returns empty. I this a wrong interpretation?
It gets spooky now. Changing to search for SUMMARY and using some fraction of the stored text as search term gave a response! Is doing text-match search on property UID prohibited or does ICalendar expect it in an undocumented way?
OK - your original UID query used a lowercase 'z' in the query string, whereas the event you are matching against has an uppercase 'Z'. In the case of UID, the UID value is actually indexed in an sqlite db and the query for that is done via SQL. Apparently the sql query is case-sensitive (which in the absence of collations is probably reasonable). Now in theory, when matching UID values you really ought to use a case-sensitive match - which is what you were originally trying to do with i;octet - so even if collations were supported, your original query would still not have worked because of the lowercase 'z'. -- Cyrus Daboo
On 04.04.2008, at 20:58, Michael Rasmussen wrote:
It gets spooky now. Changing to search for SUMMARY and using some fraction of the stored text as search term gave a response!
I think the relevant difference between SUMMARY and UID is that the latter is in the SQlite cache, hence a search is turned into a SQL query. Maybe something is fishy with that SQL query. Might be worth to check the cache and see whether it actually contains the UID you are looking for. You can find them in eg calendars/ __uids__/user01/.db.sqlite files, which in turn can be opened using sqlite3, eg: ---snip--- helge@mbp$ sqlite3 calendars/__uids__/user01/calendar/.db.sqlite SQLite version 3.5.7 Enter ".help" for instructions sqlite> SELECT NAME, TYPE FROM RESOURCE WHERE UID = '476C9580- E0B9-4CC4-9873-9791B1178D00'; 476C9580-E0B9-4CC4-9873-9791B1178D00.ics|VEVENT ---snap--- Greets, Helge -- Helge Hess http://www.helgehess.eu/
Hm, quite weird. Maybe its obvious, but in your client library you need to scan the subset result for the exact UID. As the name implies, text- match does a substring match, since '2838-2382-3827-283' could be one UID and '2838-2382-3827-2' could be another. Both resources would match a 7.8.6 UID query for '2838-2382-3827-2'. BTW: this also implies that a search by UID (instead of URL) is much slower (a LIKE %x% query, usually can't be indexed). Greets, Helge -- Helge Hess http://www.helgehess.eu/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Apr 2008 21:26:48 +0200 Helge Heß <me@helgehess.eu> wrote:
Might be worth to check the cache and see whether it actually contains the UID you are looking for. You can find them in eg calendars/ __uids__/user01/.db.sqlite files, which in turn can be opened using sqlite3, eg:
Cyrus cracked the nut. It was a matter of case. But nice to know your little trick. Might come in handy some other time:-) - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- Excellent day for putting Slinkies on an escalator. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9oekQQOPluUB9RwRAqf9AKCh8G909Qo/oVzptQksgWxGXhdZ0gCfXZ/Q fX5p9Ao2VI/ySIgG4Wyynto= =wknF -----END PGP SIGNATURE-----
participants (3)
-
Cyrus Daboo
-
Helge Heß
-
Michael Rasmussen