>ok, i've tried it with cadaver, its working the way its now.
>
>i wasn't able to connect groupdav clients... tbird + sogo didn't work at
all
>(js-errors & dead...) and I wasn't able to find out how Kontact is
configured
>these days. sick.
There may be some problems with those clients, but I'm seeing a different
problem even when using cadaver:
dav:/groupdav/Contacts/> ls
Listing collection `/groupdav/Contacts/': succeeded.
49755307-2a86-0 0 Jan 31 07:15
collected=3A_geri_qiana_gqianayd=40advsol=2Ecom 0 Jan 30
19:41
collected=3A_nonodoo9d999_nonodoo9d999=40yahoo=2Ecom 0
Feb 6 19:23
collected=3A_peta_newsmanager=40peta=2Eorg 0 Feb 6
06:40
dav:/groupdav/Contacts/> cat
collected=3A_nonodoo9d999_nonodoo9d999=40yahoo=2Ecom
Displaying
`/groupdav/Contacts/collected%3d3A_nonodoo9d999_nonodoo9d999%3d40yahoo%3d2Ec
om':
Failed: 404 not found
Someone changed the way filenames are converted back into Citadel EUID's.
I'm not quite sure yet but I think some sort of URL encoding was added.
I'll look at this too, but I'm probably going to need some help.
Here's the way it's supposed to work:
* Client does a PROPFIND to fetch the collection ("read the directory" in
layman's terms). Citadel goes through the room and fetches each message.
The EUID is encoded in quoted-printable format and sent as the filename.
(The message number becomes the ETag, but I don't think we have any
problems with that yet.)
* Server then does a GET, or DELETE, or even another PROPFIND on an
individual object. It'
s going to send that qp-encoded filename. Citadel needs to qp-decode
that filename, which it can then use as an EUID to fetch the correct
message from disk.
