Mailing List Archive: DAViCal: General

CardDAV ADR field after modifications by evolution and an iPhone

Index | Next | Previous | View Threaded

arnaud-list at aerine

Apr 20, 2012, 1:45 AM

Post #1 of 5 (357 views)
Permalink

CardDAV ADR field after modifications by evolution and an iPhone

Hi everyone,

I noticed something strange if I modify the addresses of my contacts
(CardDAV) from both evolution and an iPhone.

After a couple of modifications back and forth, the address will not be
displayed at all on the iPhone and end up broken in evolution.

I know it looks more like a client issue, but I never noticed this
during the 6 month I used davical 0.9.9.3 with the same clients. It only
appeared when I upgraded davical to 1.0.2 earlier this week so it made
me suspect davical.
Of course, it could still be a client issue, one of the client being
fine with the data served by the "old" davical but not liking the newer
one, for whatever reason (implementation of the standard, etc.).

In the logs below, you can see that the ADR field is changed like this:
ADR;TYPE=HOME:blabla --> item1.ADR;type=HOME;type=pref:blabla -->
ITEM2.ADR;TYPE=HOME;TYPE=pref:blabla.
That's when it's changed to "ITEM2.ADR" that everything goes awry. I'm
not sure what the standard says in this regard.

I would really appreciate some help/hints to clear this issue!

Versions I use:
- davical 1.0.2 (Debian "testing" package, backported to "stable")
- evolution 3.2.2 (Debian "testing")
- iPhone/iOS 4.3.1 (8G4)

Here are some logs (vcf files).

Initial creation with evolution:
----------------------------------------------------------------
BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+47.00.00.00.00
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
NICKNAME:Testy
X-EVOLUTION-SPOUSE:
NOTE:
FN:Test Name
N:Name;Test;;;
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-MOZILLA-HTML:FALSE
X-EVOLUTION-FILE-AS:Name\, Test
EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
ADR;TYPE=HOME:;;1 Main Street;Testcity;;1111;Testland
LABEL;TYPE=HOME:Test Name\n1 Main Street\n1111 TESTCITY\n\nTESTLAND
UID:ed7ff885-6b87-27d4-45b2-6511c82198ef
REV:20120419T085330Z
END:VCARD
----------------------------------------------------------------

After next modifications with evolution:
----------------------------------------------------------------
BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+47.00.00.00.00
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
NICKNAME:Testy
X-EVOLUTION-SPOUSE:
NOTE:
FN:Test Name
N:Name;Test;;;
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-MOZILLA-HTML:FALSE
ADR;TYPE=HOME:;;2 Main Street;Testcity;;1111;Testland
LABEL;TYPE=HOME:Test Name\n2 Main Street\nTestcity\, 1111\n\nTESTLAND
X-EVOLUTION-FILE-AS:Name\, Test
EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:work [at] provider
EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
UID:27943f96-90d5-4df4-793d-c388dd408e97
REV:20120419T085906Z
END:VCARD
----------------------------------------------------------------

After next modifications from the iPhone:
----------------------------------------------------------------
BEGIN:VCARD
VERSION:3.0
N:Name;Test;;;
FN:Test Name
NICKNAME:Testy
EMAIL;type=INTERNET;type=WORK;type=pref:work [at] provider
EMAIL;type=INTERNET;type=HOME:test [at] provider
TEL;type=WORK;type=pref:+47.00.00.00.00
item1.ADR;type=HOME;type=pref:;;4 Main Street;Testvillage;;3333;Samoa
item1.X-ABADR:ws
UID:ab113062-d45d-a434-658a-ceb17d1fb301
X-EVOLUTION-FILE-AS:Name\, Test
X-MOZILLA-HTML:FALSE
REV:20120419T090551Z
END:VCARD
----------------------------------------------------------------

After next modifications, again with evolution:
----------------------------------------------------------------
BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=1;TYPE=PREF:+47.00.00.00.00
N:Name;Test;;;
FN:Test Name
NICKNAME:Testy
item1.ADR;type=HOME,pref:;;5 Small Street;Testcity;;4444;Mycountry
item1.X-ABADR:ws
X-MOZILLA-HTML:FALSE
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
X-EVOLUTION-SPOUSE:
NOTE:
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-EVOLUTION-FILE-AS:Name\, Test
EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:work [at] provider
EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
LABEL;TYPE=HOME:
Test Name\n5 Small Street\nTestcity\, 4444\n\nMYCOUNTRY
UID:408523f2-ce89-f734-0d4a-c05a149fdefa
REV:20120419T090814Z
END:VCARD
----------------------------------------------------------------

After next modifications with iPhone:
----------------------------------------------------------------
BEGIN:VCARD
VERSION:3.0
N:Name;Test;;;
FN:Test Name
NICKNAME:Testy
EMAIL;type=INTERNET;type=WORK;type=pref:work [at] provider
EMAIL;type=INTERNET;type=HOME:test [at] provider
item1.TEL;type=pref:+47.00.00.00.00
ITEM2.ADR;TYPE=HOME;TYPE=pref:
\;\;6 Small Street\;Testville\;\;4444\;Marshall Islands
item2.X-ABADR:mh
UID:408523f2-ce89-f734-0d4a-c05a149fdefa
X-EVOLUTION-FILE-AS:Name\, Test
X-MOZILLA-HTML:FALSE
REV:20120419T091141Z
END:VCARD
----------------------------------------------------------------

At this point, it's a lost cause: the address is not displayed at all on
the iPhone. In evolution, instead of being nicely formatted as:
Address: 6 Small Street
City: Testville
Zip/Postal Code: 4444
Country: Marshall Islands

It will all show up as:
Address: /empty/
City: /empty/
Zip/Postal Code: /empty/
Country: /empty/
PO Box: ;;6 Small Street;Testville;;4444;Marshall Islands

Best regards,

--
Arnaud

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

marten.gajda at googlemail

Apr 20, 2012, 5:42 AM

Post #2 of 5 (354 views)
Permalink

Re: CardDAV ADR field after modifications by evolution and an iPhone [In reply to]

Hi Arnaud,

Here is the problem:

ITEM2.ADR;TYPE=HOME;TYPE=pref:
\;\;6 Small Street\;Testville\;\;4444\;Marshall Islands

After the modification on iPhone all ";" are escaped. They are no longer
field separators, thus the whole line goes to "PO Box".

I can't tell you why your iPhone does that, but I'm pretty sure it's not
a server issue.

On a first glace the last Evolution vCard looks valid to me.

cheers

Marten

Am 20.04.2012 10:45, schrieb Arnaud:
> Hi everyone,
>
> I noticed something strange if I modify the addresses of my contacts
> (CardDAV) from both evolution and an iPhone.
>
> After a couple of modifications back and forth, the address will not be
> displayed at all on the iPhone and end up broken in evolution.
>
> I know it looks more like a client issue, but I never noticed this
> during the 6 month I used davical 0.9.9.3 with the same clients. It only
> appeared when I upgraded davical to 1.0.2 earlier this week so it made
> me suspect davical.
> Of course, it could still be a client issue, one of the client being
> fine with the data served by the "old" davical but not liking the newer
> one, for whatever reason (implementation of the standard, etc.).
>
> In the logs below, you can see that the ADR field is changed like this:
> ADR;TYPE=HOME:blabla --> item1.ADR;type=HOME;type=pref:blabla -->
> ITEM2.ADR;TYPE=HOME;TYPE=pref:blabla.
> That's when it's changed to "ITEM2.ADR" that everything goes awry. I'm
> not sure what the standard says in this regard.
>
> I would really appreciate some help/hints to clear this issue!
>
> Versions I use:
> - davical 1.0.2 (Debian "testing" package, backported to "stable")
> - evolution 3.2.2 (Debian "testing")
> - iPhone/iOS 4.3.1 (8G4)
>
>
> Here are some logs (vcf files).
>
> Initial creation with evolution:
> ----------------------------------------------------------------
> BEGIN:VCARD
> VERSION:3.0
> TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+47.00.00.00.00
> URL:
> TITLE:
> ROLE:
> X-EVOLUTION-MANAGER:
> X-EVOLUTION-ASSISTANT:
> NICKNAME:Testy
> X-EVOLUTION-SPOUSE:
> NOTE:
> FN:Test Name
> N:Name;Test;;;
> X-EVOLUTION-BLOG-URL:
> CALURI:
> FBURL:
> X-EVOLUTION-VIDEO-URL:
> X-MOZILLA-HTML:FALSE
> X-EVOLUTION-FILE-AS:Name\, Test
> EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
> ADR;TYPE=HOME:;;1 Main Street;Testcity;;1111;Testland
> LABEL;TYPE=HOME:Test Name\n1 Main Street\n1111 TESTCITY\n\nTESTLAND
> UID:ed7ff885-6b87-27d4-45b2-6511c82198ef
> REV:20120419T085330Z
> END:VCARD
> ----------------------------------------------------------------
>
>
> After next modifications with evolution:
> ----------------------------------------------------------------
> BEGIN:VCARD
> VERSION:3.0
> TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+47.00.00.00.00
> URL:
> TITLE:
> ROLE:
> X-EVOLUTION-MANAGER:
> X-EVOLUTION-ASSISTANT:
> NICKNAME:Testy
> X-EVOLUTION-SPOUSE:
> NOTE:
> FN:Test Name
> N:Name;Test;;;
> X-EVOLUTION-BLOG-URL:
> CALURI:
> FBURL:
> X-EVOLUTION-VIDEO-URL:
> X-MOZILLA-HTML:FALSE
> ADR;TYPE=HOME:;;2 Main Street;Testcity;;1111;Testland
> LABEL;TYPE=HOME:Test Name\n2 Main Street\nTestcity\, 1111\n\nTESTLAND
> X-EVOLUTION-FILE-AS:Name\, Test
> EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:work [at] provider
> EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
> UID:27943f96-90d5-4df4-793d-c388dd408e97
> REV:20120419T085906Z
> END:VCARD
> ----------------------------------------------------------------
>
> After next modifications from the iPhone:
> ----------------------------------------------------------------
> BEGIN:VCARD
> VERSION:3.0
> N:Name;Test;;;
> FN:Test Name
> NICKNAME:Testy
> EMAIL;type=INTERNET;type=WORK;type=pref:work [at] provider
> EMAIL;type=INTERNET;type=HOME:test [at] provider
> TEL;type=WORK;type=pref:+47.00.00.00.00
> item1.ADR;type=HOME;type=pref:;;4 Main Street;Testvillage;;3333;Samoa
> item1.X-ABADR:ws
> UID:ab113062-d45d-a434-658a-ceb17d1fb301
> X-EVOLUTION-FILE-AS:Name\, Test
> X-MOZILLA-HTML:FALSE
> REV:20120419T090551Z
> END:VCARD
> ----------------------------------------------------------------
>
> After next modifications, again with evolution:
> ----------------------------------------------------------------
> BEGIN:VCARD
> VERSION:3.0
> TEL;X-EVOLUTION-UI-SLOT=1;TYPE=PREF:+47.00.00.00.00
> N:Name;Test;;;
> FN:Test Name
> NICKNAME:Testy
> item1.ADR;type=HOME,pref:;;5 Small Street;Testcity;;4444;Mycountry
> item1.X-ABADR:ws
> X-MOZILLA-HTML:FALSE
> URL:
> TITLE:
> ROLE:
> X-EVOLUTION-MANAGER:
> X-EVOLUTION-ASSISTANT:
> X-EVOLUTION-SPOUSE:
> NOTE:
> X-EVOLUTION-BLOG-URL:
> CALURI:
> FBURL:
> X-EVOLUTION-VIDEO-URL:
> X-EVOLUTION-FILE-AS:Name\, Test
> EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:work [at] provider
> EMAIL;X-EVOLUTION-UI-SLOT=2;TYPE=HOME:test [at] provider
> LABEL;TYPE=HOME:
> Test Name\n5 Small Street\nTestcity\, 4444\n\nMYCOUNTRY
> UID:408523f2-ce89-f734-0d4a-c05a149fdefa
> REV:20120419T090814Z
> END:VCARD
> ----------------------------------------------------------------
>
> After next modifications with iPhone:
> ----------------------------------------------------------------
> BEGIN:VCARD
> VERSION:3.0
> N:Name;Test;;;
> FN:Test Name
> NICKNAME:Testy
> EMAIL;type=INTERNET;type=WORK;type=pref:work [at] provider
> EMAIL;type=INTERNET;type=HOME:test [at] provider
> item1.TEL;type=pref:+47.00.00.00.00
> ITEM2.ADR;TYPE=HOME;TYPE=pref:
> \;\;6 Small Street\;Testville\;\;4444\;Marshall Islands
> item2.X-ABADR:mh
> UID:408523f2-ce89-f734-0d4a-c05a149fdefa
> X-EVOLUTION-FILE-AS:Name\, Test
> X-MOZILLA-HTML:FALSE
> REV:20120419T091141Z
> END:VCARD
> ----------------------------------------------------------------
>
>
> At this point, it's a lost cause: the address is not displayed at all on
> the iPhone. In evolution, instead of being nicely formatted as:
> Address: 6 Small Street
> City: Testville
> Zip/Postal Code: 4444
> Country: Marshall Islands
>
> It will all show up as:
> Address: /empty/
> City: /empty/
> Zip/Postal Code: /empty/
> Country: /empty/
> PO Box: ;;6 Small Street;Testville;;4444;Marshall Islands
>
>
>
> Best regards,
>

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

andrew at morphoss

Apr 20, 2012, 5:51 PM

Post #3 of 5 (345 views)
Permalink

Re: CardDAV ADR field after modifications by evolution and an iPhone [In reply to]

On Fri, 2012-04-20 at 10:45 +0200, Arnaud wrote:
> Hi everyone,
>
> I noticed something strange if I modify the addresses of my contacts
> (CardDAV) from both evolution and an iPhone.
>
> After a couple of modifications back and forth, the address will not be
> displayed at all on the iPhone and end up broken in evolution.
>
> I know it looks more like a client issue, but I never noticed this
> during the 6 month I used davical 0.9.9.3 with the same clients. It only
> appeared when I upgraded davical to 1.0.2 earlier this week so it made
> me suspect davical.
> Of course, it could still be a client issue, one of the client being
> fine with the data served by the "old" davical but not liking the newer
> one, for whatever reason (implementation of the standard, etc.).
>
> In the logs below, you can see that the ADR field is changed like this:
> ADR;TYPE=HOME:blabla --> item1.ADR;type=HOME;type=pref:blabla -->
> ITEM2.ADR;TYPE=HOME;TYPE=pref:blabla.
> That's when it's changed to "ITEM2.ADR" that everything goes awry. I'm
> not sure what the standard says in this regard.
>
> I would really appreciate some help/hints to clear this issue!
>
> Versions I use:
> - davical 1.0.2 (Debian "testing" package, backported to "stable")
> - evolution 3.2.2 (Debian "testing")
> - iPhone/iOS 4.3.1 (8G4)

It's curious that the iPhone is escaping the semicolons, which are used
to separate the various address parts. It's peculiar that it changes it
to ITEM2.ADR from being item1.ADR previously, as it chooses to make TEL
into item1.TEL on that modification but not earlier ones.

On Evolution's side it seems to be changing the UID, and inserting a
whole lot of silly null properties. The UID issue is a known problem.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Avoid reality at all costs.
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

arnaud-list at aerine

Apr 23, 2012, 2:22 AM

Post #4 of 5 (338 views)
Permalink

Re: CardDAV ADR field after modifications by evolution and an iPhone [In reply to]

Hi Andrew, Marten,

and thanks for your help! I did more tests: see below.

Andrew wrote:

> It's curious that the iPhone is escaping the semicolons, which are used
> to separate the various address parts. It's peculiar that it changes it
> to ITEM2.ADR from being item1.ADR previously, as it chooses to make TEL
> into item1.TEL on that modification but not earlier ones.

I tried to investigate with full davical debug, and it looks like it's
davical and not the iPhone that is escaping the semicolons.

Could it be that davical is confused by the "item2.ADR" field and
escaping its content?

I may be wrong, though. Could you guys help me analyse the log of the
last (4th) modification?

The PUT request looks like:
request:-->item2.ADR;type=HOME;type=pref:;;5 Small
Street;Testville;;4444;Marshall Islands
but the reply sent by davical is:
response:-->ITEM2.ADR;TYPE=HOME;TYPE=pref:
response:--> \\;\\;5 Small Street\\;Testville\\;\\;4444\\;Marshall Islands

------------------------------------------------------------------------
davical: LOG: :******************** Request ********************
davical: LOG: request:-->BEGIN:VCARD
davical: LOG: request:-->VERSION:3.0
davical: LOG: request:-->N:Pouet;Pouetounet;;;
davical: LOG: request:-->FN:Pouetounet Pouet
davical: LOG: request:-->NICKNAME:Pouety
davical: LOG:
request:-->EMAIL;type=INTERNET;type=HOME;type=pref:test [at] testprovider
davical: LOG: request:-->item1.TEL;type=pref:+4700000000
davical: LOG: request:-->item2.ADR;type=HOME;type=pref:;;5 Small
Street;Testville;;4444;Marshall Islands
davical: LOG: request:-->item2.X-ABADR:mh
davical: LOG: request:-->UID:51fda95d-bf68-b8d4-5926-b54ed90650a0
davical: LOG: request:-->X-EVOLUTION-FILE-AS:Pouet\\, Pouetounet
davical: LOG: request:-->X-MOZILLA-HTML:FALSE
davical: LOG: request:-->END:VCARD
davical: LOG: request:-->

[...]

davical: LOG: response:--> <response>
davical: LOG: response:-->
<href>/caldav.php/arnaud/contacts/1AC9AE26-77E1A5A9-1DD9F108.vcf</href>
davical: LOG: response:--> <propstat>
davical: LOG: response:--> <prop>
davical: LOG: response:-->
<getetag>"1149d574256b326490f4b1777ac7d42d"</getetag>
davical: LOG: response:--> <VC:address-data>BEGIN:VCARD
davical: LOG: response:-->VERSION:3.0
davical: LOG: response:-->N:Pouet;Pouetounet;;;
davical: LOG: response:-->FN:Pouetounet Pouet
davical: LOG: response:-->NICKNAME:Pouety
davical: LOG:
response:-->EMAIL;type=INTERNET;type=HOME;type=pref:test [at] testprovider
davical: LOG: response:-->item1.TEL;type=pref:+4700000000
davical: LOG: response:-->ITEM2.ADR;TYPE=HOME;TYPE=pref:
davical: LOG: response:--> \\;\\;5 Small
Street\\;Testville\\;\\;4444\\;Marshall Islands
davical: LOG: response:-->item2.X-ABADR:mh
davical: LOG: response:-->UID:51fda95d-bf68-b8d4-5926-b54ed90650a0
davical: LOG: response:-->X-EVOLUTION-FILE-AS:Pouet\\, Pouetounet
davical: LOG: response:-->X-MOZILLA-HTML:FALSE
davical: LOG: response:-->REV:20120423T083255Z
davical: LOG: response:-->END:VCARD
davical: LOG: response:--></VC:address-data>
davical: LOG: response:--> </prop>
davical: LOG: response:--> <status>HTTP/1.1 200 OK</status>
davical: LOG: response:--> </propstat>
davical: LOG: response:--> </response>
------------------------------------------------------------------------

I just pasted here the important bits, but the (mostly) full log is
attached to the email, with data related to other non-test contacts removed.

Best regards,

--
Arnaud

Attachments:

semicolons_escaped_davical.log (19.3 KB)

andrew at morphoss

Apr 27, 2012, 1:37 AM

Post #5 of 5 (338 views)
Permalink

Re: CardDAV ADR field after modifications by evolution and an iPhone [In reply to]

On Mon, 2012-04-23 at 11:22 +0200, Arnaud wrote:
> Hi Andrew, Marten,
>
>
> and thanks for your help! I did more tests: see below.
>
>
> Andrew wrote:
>
> > It's curious that the iPhone is escaping the semicolons, which are used
> > to separate the various address parts. It's peculiar that it changes it
> > to ITEM2.ADR from being item1.ADR previously, as it chooses to make TEL
> > into item1.TEL on that modification but not earlier ones.
>
> I tried to investigate with full davical debug, and it looks like it's
> davical and not the iPhone that is escaping the semicolons.
>
> Could it be that davical is confused by the "item2.ADR" field and
> escaping its content?

Hi Arnaud,

This seems unlikely. You show item2.ADR changing case to ITEM2.ADR at
the same time as item1.ADR retains it's lowercase feature. In general
DAViCal does not change the content it's given, storing it purely "as
given" and handing it back on request. There is *no* code in DAViCal to
do that kind of manipulation on VCARD content - only for VCALENDAR
content, which is used for obfuscating confidential events.

Furthermore, if DAViCal were doing what you say, then it would be doing
it all over the place, rather than in this one curious instance.

The request you show is a PUT request, and the response you show is a
subsequent addressbook-query REPORT.

Rather than enabling *all* logging, which can be problematic and
verbose, and is really only designed for use by developers, you might
want to look at a simpler debug setting like:

$c->dbg = array( 'request' => 1, 'statistics' => 1 );

This will log every request against DAViCal in full (just one of the
things that you get with 'all' enabled) but without all of the many many
other complications of the full developer debug logging.

Since DAViCal's configuration file is actually just PHP code that gets
included into the program, you can be sneakier and restrict the
debugging only to traffic from your client's IP address:

if ( $_SERVER['REMOTE_ADDR'] == '192.67.23.151' ) {
$c->dbg = array( 'request' => 1, 'statistics' => 1 );
}
else {
$c->dbg = array();
}

Where you change the 192.67.23.151 to the IP address of your computer
making all the requests.

The other thing you can do is look into the database. if you do
something like:

psql -U davical_app davical

you can enter SQL like:

SELECT caldav_data FROM caldav_data WHERE dav_name =
'/principal/addressbook/51fda95d-bf68-b8d4-5926-b54ed90650a0.vcf';

Where that /principal/addressbook... is the path of the vcard on DAViCal
with the '.../caldav.php' bit at the front removed.

One thing to check is the PRODID value, although I'm not sure if CardDAV
clients maintain this field as aggressively as CalDAV clients do.

Cheers,
Andrew.

> I may be wrong, though. Could you guys help me analyse the log of the
> last (4th) modification?
>
> The PUT request looks like:
> request:-->item2.ADR;type=HOME;type=pref:;;5 Small
> Street;Testville;;4444;Marshall Islands
> but the reply sent by davical is:
> response:-->ITEM2.ADR;TYPE=HOME;TYPE=pref:
> response:--> \\;\\;5 Small Street\\;Testville\\;\\;4444\\;Marshall Islands
>
> ------------------------------------------------------------------------
> davical: LOG: :******************** Request ********************
> davical: LOG: request:-->BEGIN:VCARD
> davical: LOG: request:-->VERSION:3.0
> davical: LOG: request:-->N:Pouet;Pouetounet;;;
> davical: LOG: request:-->FN:Pouetounet Pouet
> davical: LOG: request:-->NICKNAME:Pouety
> davical: LOG:
> request:-->EMAIL;type=INTERNET;type=HOME;type=pref:test [at] testprovider
> davical: LOG: request:-->item1.TEL;type=pref:+4700000000
> davical: LOG: request:-->item2.ADR;type=HOME;type=pref:;;5 Small
> Street;Testville;;4444;Marshall Islands
> davical: LOG: request:-->item2.X-ABADR:mh
> davical: LOG: request:-->UID:51fda95d-bf68-b8d4-5926-b54ed90650a0
> davical: LOG: request:-->X-EVOLUTION-FILE-AS:Pouet\\, Pouetounet
> davical: LOG: request:-->X-MOZILLA-HTML:FALSE
> davical: LOG: request:-->END:VCARD
> davical: LOG: request:-->
>
> [...]
>
> davical: LOG: response:--> <response>
> davical: LOG: response:-->
> <href>/caldav.php/arnaud/contacts/1AC9AE26-77E1A5A9-1DD9F108.vcf</href>
> davical: LOG: response:--> <propstat>
> davical: LOG: response:--> <prop>
> davical: LOG: response:-->
> <getetag>"1149d574256b326490f4b1777ac7d42d"</getetag>
> davical: LOG: response:--> <VC:address-data>BEGIN:VCARD
> davical: LOG: response:-->VERSION:3.0
> davical: LOG: response:-->N:Pouet;Pouetounet;;;
> davical: LOG: response:-->FN:Pouetounet Pouet
> davical: LOG: response:-->NICKNAME:Pouety
> davical: LOG:
> response:-->EMAIL;type=INTERNET;type=HOME;type=pref:test [at] testprovider
> davical: LOG: response:-->item1.TEL;type=pref:+4700000000
> davical: LOG: response:-->ITEM2.ADR;TYPE=HOME;TYPE=pref:
> davical: LOG: response:--> \\;\\;5 Small
> Street\\;Testville\\;\\;4444\\;Marshall Islands
> davical: LOG: response:-->item2.X-ABADR:mh
> davical: LOG: response:-->UID:51fda95d-bf68-b8d4-5926-b54ed90650a0
> davical: LOG: response:-->X-EVOLUTION-FILE-AS:Pouet\\, Pouetounet
> davical: LOG: response:-->X-MOZILLA-HTML:FALSE
> davical: LOG: response:-->REV:20120423T083255Z
> davical: LOG: response:-->END:VCARD
> davical: LOG: response:--></VC:address-data>
> davical: LOG: response:--> </prop>
> davical: LOG: response:--> <status>HTTP/1.1 200 OK</status>
> davical: LOG: response:--> </propstat>
> davical: LOG: response:--> </response>
> ------------------------------------------------------------------------
>
> I just pasted here the important bits, but the (mostly) full log is
> attached to the email, with data related to other non-test contacts removed.
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Were these parsnips CORRECTLY MARINATED in TACO SAUCE?
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads