I can confirm Rolf's problem. Situation here: Ubuntu 9.04 with Evolution 2.26.1 on the client side, and Ubuntu 8.04 Server with Apple calendarserver 1.2.dfsg-6 on the server side. URL that I tried to use in the Evolution CalDAV setup dialog (see also http://trac.calendarserver.org/wiki/CalendarClients): https://<myserver>:8443/calendars/users/<myuser>/calendar (seems to be "corrected" to caldav://<myserver>:8443/calendars/users/<myuser>/calendar). When I try to add an appointment, Evolution complains with "no such calendar" (english translation of the German error message "Kein derartiger Kalender"). iCal and Thunderbird+Lightning (0.9+nobinonly-0ubuntu2) work fine though. Everything else is just like Rolfs' setup.

it's of course Ubuntu 8.10 Server and not Ubuntu 8.04 Server

Hi both, last time I tested to connect there was quite long time ago, but it worked. Maybe I something changed in wrongly. Anyway, please try this:
a) close evolution, then invoke on console: evolution --force-shutdown
b) open new console and run there:
   $ CALDAV_DEBUG=all /usr/lib/evolution-data-server-2.26
   Maybe the executable is stored somewhere else, I have in in libexec, instead
   of lib, but that's other system.
c) run evolution from the previous console, and watch both of them. When it'll
   try to connect to the server, you should see new values on the eds console.

Possibly related bug, I can think of:
bug #578335 - not stored passwords in key-ring. It's about:
> (evolution:5708): e-data-server-ui-CRITICAL **: ep_keyring_insert_password:
> assertion `user != NULL' failed

Today's change there fixes usernames with '@' in it too. If that's your case,
please try using "%40" instead of "@" in the username.

Hi Milan,

I don't understand how I can check wether bug # 578335 is the case here.

The CalDAV account is neither stored in ~/.gnome2_private/evolution nor in the keyring (as far as I can see with Seahorse). IMAP and LDAP run fine though.

I checked your points a) to c) and got the following:

Starting Evo from the terminal after forcing shutdown and starting the e-d-s in caldav_debug mode brought me right into the calendar module and pwd request for my caldav account. After entering it the e-s-d console said:

###

impl_GNOME_Evolution_Addressbook_BookFactory_getBook
 + file:///home/eder/.evolution/addressbook/local/system
 => 0x83d1bb0
impl_GNOME_Evolution_Addressbook_Book_open (0x83d1bb0)

(evolution-data-server-2.26:16432): libedata-book-WARNING **: impl_GNOME_Evolution_Addressbook_Book_getBookView ((contains "x-evolution-any-field" ""))

e_data_book_respond_get_book_view
book_view file uref 

###

and the evo console:

###

e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: Keine passenden Ergebnisse)
e-data-server-ui-Message: Key file does not have group 'Passwords-Calendar'

(evolution:16818): e-data-server-ui-CRITICAL **: ep_keyring_insert_password: assertion `user != NULL' failed

(evolution:16818): calendar-gui-WARNING **: Unable to load the calendar Unbekannter Fehler 

###

There was _nothing_ in the log on the caldavd. I checked with tcpdump and found no caldav related traffic beween evo client and iCal server. With whom is evo talking  other than himself? I suppose it's all about a local e-d-s pwd problem and maybe the bug mentioned above. Suggestions welcome.
-- 
Rolf

(In reply to comment #4)
> I don't understand how I can check wether bug # 578335 is the case here.

It was meant to '@' in your user name, not to that bug number.

> There was _nothing_ in the log on the caldavd. I checked with tcpdump and found
> no caldav related traffic beween evo client and iCal server. With whom is evo
> talking  other than himself? I suppose it's all about a local e-d-s pwd problem
> and maybe the bug mentioned above. Suggestions welcome.

Yes, there is supposed to be some communication between eds and your server, quite long log of that communication on eds console. It seems, from your description, that the URL given to the backend is incorrectly formed, probably because of some issue in a calendar setup. Could you check your CalDAV calendar preferences, what URL it shows there? (I would like to see it, though with changed address and username, except of any special characters in there, if any included.)

Hi Milan,

tx for your fast reply.

Working URL from ical.app (Mac OS X - CalDAV account is configured automatically via Open Directory, no need to enter the UID manually:-)

http://<addr>:8008/principals/__uids__/96E7554D-96FD-4435-BC10-6CA77EF16031/

Working URL in Lightning 0.9 / 1.0pre (all platforms):

http://<addr>:8008/calendars/users/<usr>/calendar/

NOT working URL in Evo (tried also every (?) possible variation after the port number, even copied the weird UID from iCal):

caldav://<addr>:8008/calendars/users/<usr>/calendar/

usr is plain ascii, four letters only.

There is definitely no attempt from Evo to connect to the Apple iCal srv :-( The URL and pwd is stored nowhere - independent from the state of "save pwd" in the pwd dialogue.

Possible debug setup?

TIA
-- 
Rolf

I just tried with Evolution 2.26.3, connecting to my local Darwin server:
 $ svn info
URL: http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk
Repository Root: http://svn.calendarserver.org/repository/calendarserver
Repository UUID: e27351fd-9f3e-4f54-a53b-843176b1656c
Revision: 4307
Node Kind: directory
Schedule: normal
Last Changed Author: sagen .. app...
Last Changed Rev: 4307
Last Changed Date: 2009-05-21 20:26:08 +0200 (Thu, 21 May 2009)

and when running this as a user, and connection to
URL: caldav://localhost:8008/calendars/users/admin/calendar/
Use SSL: not checked
Username: admin
then it works fine, I can see events created from sunbird, and it can see events created from evolution. No issue so far.

Could you try to catch me on IRC for some live debugging, as it'll be easier to do than describing here bunch of gdb commands, please? Just install debug info packages for evolution and evolution-data-server, so we will have those ready. Thanks.

Hi Milan,

thank you very much for the gdb session over IRC! I still hope we get our 40+ clients to Evo ...

Summary so far: Evo has a problem working with system default proxy. Disabling proxy or setting it manually starts talking with caldavd but receives HTTP 401.

Apple iCal Srv 10.5.x just recognizes Digest or Kerberos pwd and the error log states "[...] Open Directory (node=/Search) error while performing digest authentication for user <usr>: missing digest response field: 'algorithm' in: {'username': '<usr>', 'nonce': '<some hash>', 'realm': '/Search', 'uri': '/calendars/users/<usr>/calendar/', 'response': '< another hash>'}"

Conclusion: aside the proxy prob we have a prob with auth.

Hope to catch Milan back on IRC later or tomorrow :-)
-- 
Rolf

Thanks for the update, I got disconnected after my proxy had been set, and I can confirm that evolution doesn't play well with it, though it seems the only issue is the port defined in the URL for the Apple iCal server. EProxy doesn't return any proxy for such defined uri, thus the proxy is bypassed, and it simply doesn't work. I will try to investigate what one can do with that. Thanks for your help discovering this.

(In reply to comment #8)
> Apple iCal Srv 10.5.x just recognizes Digest or Kerberos pwd and the error log
> states "[...] Open Directory (node=/Search) error while performing digest
> authentication for user <usr>: missing digest response field: 'algorithm' in:
> {'username': '<usr>', 'nonce': '<some hash>', 'realm': '/Search', 'uri':
> '/calendars/users/<usr>/calendar/', 'response': '< another hash>'}"

I believe this is from the browser, we tried the URL there too, as evolution bypassed proxy and couldn't connect there.

Hi,

I doublechecked the CalDAV access from the browser with and without proxy: Both contact the caldavd and get XML stuff (collection listing), nothing seriuos in the access.log or error.log on the server side, browser cache was cleared between the attempts. So the prob is not the proxy in general.

The proxy is plain Squid, no auth, standard port 3128.

I repeated the attempts with Evo (e-d-s restarted between attemps):

System default proxy = Evo ist talking to himself, no connect to caldavd.

Manual proxy (same settings as above) = caldavd access.log spits out HTTP err 401 and error.log shows the lines mentioned in comment #8.

No proxy = same results as with manual proxy.

Conclusion: Evo doesn't read the default proxy well and has auth probs with caldavd in general. Possible hint in caldavd error.log seems to be "missing digest response field: 'algorithm'".

The error.log comes from:
http://svn.calendarserver.org/repository/calendarserver/CalendarServer/branches/release/CalendarServer-2.2-dev/twistedcaldav/directory/appleopendirectory.py

Quote from a comment in that code:

# We need a special format for the "challenge" and "response" strings passed into open directory, as it is picky about exactly what it receives.

+++

I would split the bug into two: proxy and auth. Concerning auth I could check against the latest 10.5.x release (production is 10.5.6, over the weekend I could check 10.5.7) and the 10.6 beta. Stay tuned.

Now it's time for the Champions League final :-)

cu
-- 
Rolf

Thanks for the testing. Seems my guesses are incorrect. :) But please wait with a new bug, as I have this working fine without proxy, on a local machine, thus this should be something with proxy in Evolution, not with the auth.

Err, bad, I just tried to play with the proxy a bit more, I configured my PC to connect to the machine with the Apple iCal server only through proxy, and as far as I can tell, it works, even with 2.26.2. That's strange. (My previous tests with local machine are incorrect, as far as I can tell.)

I had a chat with a libsoup coder, and he pointed me to bug #498484, with respect of authentication issues, and he also asked me to ask you for more detailed information, as your caldav is finally trying to connect to your server. 
Please do open a console, close evolution, then invoke:
   $ evolution --force-shutdown
   $ export CALDAV_DEBUG=all
   $ /usr/lib/evolution/evolution-data-server-2.26
and run evolution either from some other console or anyhow, and try to open the remote CalDAV calendar. We are interested in the communication between your machine and the server, as should be shown on the eds console. Please strip from there any private information and upload it here. Thanks in advance.

Hi,

I'm curious why you are still thinking it's a proxy related bug: The error.log on the caldavd shows the same msg with or without proxy (where access.log and tcpdump tell me Evo has a direct connection without proxy being involved).

Furthermore investigation: Evo doesn't read the network setting "system default proxy" well when the system setting uses a proxy auto-config (or at least doesn't like the proxy.pac in our network aka http://intranet:8000/proxy.pac). System setting to manual proxy with squid addr on port 3128 and system default proxy in Evo network settings brings up the repeating pwd question (same as manual proxy or no proxy in Evo network settings). Errors in error.log are pretty the same then - independent from proxy yes/no.

Here is the e-d-s info from the console trying to contact caldavd (all independet from proxy = yes / no / perhaps) - Evo is starting right into the calendar and tries to open the caldav store:

[...]
evolution-data-server-Message: Server up and running
impl_GNOME_Evolution_Addressbook_BookFactory_getBook
 + file:///home/<usr>/.evolution/addressbook/local/system
 => 0x8a154f0
impl_GNOME_Evolution_Addressbook_Book_open (0x8a154f0)

(evolution-data-server-2.26:31470): libedata-book-WARNING **: impl_GNOME_Evolution_Addressbook_Book_getBookView ((contains "x-evolution-any-field" ""))

e_data_book_respond_get_book_view
book_view file uref 

/* Here we are when the calendar asks for the caldav pwd */

> OPTIONS /calendars/users/<usr>/calendar/ HTTP/1.1
> Soup-Debug-Timestamp: 1243606450
> Soup-Debug: SoupSessionSync 1 (0x9e77018), SoupMessage 1 (0x9ebec00), SoupSocket 1 (0x9e79978)
> Host: <addr>:8008
> User-Agent: Evolution/2.26.1.1
  
< HTTP/1.1 401 Unauthorized
< Soup-Debug-Timestamp: 1243606450
< Soup-Debug: SoupMessage 1 (0x9ebec00)
< Date: Fri, 29 May 2009 14:13:56 GMT
< Content-Length: 141
< Content-Type: text/html
< WWW-Authenticate: digest nonce="6960413051231248617840502477", realm="/Search", algorithm="md5"
< Server: Twisted/2.5.0 TwistedWeb/[twisted.web2, version 0.2.0]
< 
< <html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>You are not authorized to access this resource.</p></body></html>
  
> OPTIONS /calendars/users/<usr>/calendar/ HTTP/1.1
> Soup-Debug-Timestamp: 1243606450
> Soup-Debug: SoupSessionSync 1 (0x9e77018), SoupMessage 1 (0x9ebec00), SoupSocket 1 (0x9e79978), restarted
> Host: <addr>:8008
> User-Agent: Evolution/2.26.1.1
> Authorization: Digest username="<usr>", realm="/Search", nonce="6960413051231248617840502477", uri="/calendars/users/<usr>/calendar/", response="ca42c60a0e1052cdf477cd1f735b560e"
  
< HTTP/1.1 401 Unauthorized
< Soup-Debug-Timestamp: 1243606451
< Soup-Debug: SoupMessage 1 (0x9ebec00)
< Date: Fri, 29 May 2009 14:13:56 GMT
< Content-Length: 141
< Content-Type: text/html
< WWW-Authenticate: digest nonce="15688451561144256056613393952", realm="/Search", algorithm="md5"
< Server: Twisted/2.5.0 TwistedWeb/[twisted.web2, version 0.2.0]
< 
< <html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>You are not authorized to access this resource.</p></body></html>

/* Here we are when the pwd was entered once and the same dialogue reappears */

I will update the srv over the weekend to 10.5.7 (that will update the caldavd too) and ask a friend for some testing on the 10.6 beta (new caldavd trunk there)

HTH and happy debugging
-- 
Rolf

ok, bug #498484 was about Apple's calendar server only supporting the older form of Digest auth. Now it seems that they support the newer form, but incorrectly; they require the "algorithm" field to be present in the response, even though the spec says that it's optional and 'If this is not present it is assumed to be "MD5".'

We can work around this by just always explicitly sending algorithm, but this should probably be reported as a bug to Apple too.

As a workaround for you until there's either a new libsoup or a new caldavd, if you can configure the server to not allow Digest auth, then it should work fine with Basic auth. (It looks like you're using SSL anyway, so this wouldn't be any less secure.)

Fixed in git. Will be in libsoup 2.26.3.

Hi Dan,

I filed this bug as ID 6939942 to Apple. The current ver 10.5.7 doesn't cure this.

Where can I find libsoup 2.26.3? My system is running with 2.26.2-1 as of today.

I'd like to check the prob with the new libsoup to make sure it's working then.

TIA
-- 
Rolf

2.26.3 doesn't exist yet. it will be released (along with the rest of GNOME 2.26.3) on June 29.

If you want to test it, rebuild your libsoup with this patch:
http://git.gnome.org/cgit/libsoup/patch/?id=3dcdf7f79c319a3f392ffef3f26cde025e3a88f3

Hi Dan,

thanks a lot for your input, but I'm afraid that patching libsoup is beyond my abilities. I downloaded the sources but soup-auth-digest.c is still missing. Even what comes next remains a mystery as I never used git before ... I'm an admin not a programmer :-)

Could you direct me to a link for a patched libsoup ready for testing so I could confirm the patch works?

TIA
-- 
Rolf

um... if you're running Fedora I could probably manage to create a patched RPM for you. (Just tell me what release/architecture.) I have no access to build machines for any other distros.

Hi Dan,

it's Debian 5 on i386. What about alienating your RPM into a deb-package? For testing only it might be worth a shot. Just send me an patched RPM for the latest Fedora release on i386.

Or is there somebody out there who can guide me trough the patching on Lenny?

TIA
-- 
Rolf

2.26.3 is out now, so this should be fixed in that