In Zimbra's logs, there seems to be a possibly relevant INFO entry about a DAV redirect:

2014-10-02 10:36:52,635 INFO
[qtp865089657-1858569:http://<core server>/dav/<user email>/Calendar/1412239147.R257.ics]
[aname=<user email>;ip=<front server IP>;oip=<client IP>;ua=Mozilla/5.0
(X11;; Linux x86_64) KHTML/4.14.1 (like Gecko) Konqueror/4.14;] dav - sending
redirect
2014-10-02 10:36:52,635 INFO
[qtp865089657-1858569:http://<core server>/dav/<user email>/Calendar/1412239147.R257.ics]
[aname=<user email>;ip=<front server IP>;;oip=<client IP>;ua=Mozilla/5.0
(X11;; Linux x86_64) KHTML/4.14.1 (like Gecko) Konqueror/4.14;] dav - sending
http error 302 because: wrong url - redirecting to:
https://<front server>/dav/<user email>/Calendar/53ef9fd5-9e29-45cb-9da8-98958f53fd98.ics

Is it possible that the filename of the event is not correct? (Zimbra seems to be expecting the filename to be <UID>.ics).

Using Lightning in Thunderbird works, and Zimbra's logs show:

2014-10-03 16:21:38,140 INFO
[qtp865089657-2107138:http://<core server>/dav/<user email>/Calendar/]
[aname=<user email>;ip=<front server IP>;oip=<client IP>;ua=Mozilla/5.0
(X11;; Linux x86_64) KHTML/4.14.1 (like Gecko) Konqueror/4.14;]
FileUploadServlet - saveUpload(): received Upload: {
accountId=1cc707ae-d05e-46f0-b9f0-a00d1d329d7a, time=Fri Oct 03 16:21:38 CEST
2014, size=513,
uploadId=f6388315-358a-446e-a2db-473ea7b91bd8:cc5e53cc-7549-45de-b174-ad4c6fce4d80,
name=null, path=null }


I'm also attaching the debug output of akonadiconsole when hitting "restart" (when the agent is in a broken state).

Created attachment 88944 [details]
Akonadiconsole debug output

Hi Benjamin,

It may be linked to a URL encoding issue spotted two days ago by another person, and that's been fixed. Not 100% sure but as the URL contains the user email it's likely.

Can you compile the resource and test? If you need help just ping me.

Cheers,
Grégory

I've tried the patch from the GIT commit 691bbcc4aadfb7f1cf75d5767d4becf73441a4ce directly on kdepim-runtime 4.14.1, but with no luck.

Actually, the line in question is never executed since the error happens right when the function davJobFinished begins, i.e. the job itself is in an error state.


I tried also to add some debug lines in the code to see what is happening in the background. In DavItemCreateJob::start(), the url the data is sent to is the wrong one according to Zimbra (the one referenced in Zimbra's logs). Zimbra claims to send a 302 error code with the correct location, but the headers of the response as got in DavItemCreateJob::davJobFinished() only references a "401 must authenticate" (without any location).

Is it possible that KIO::StoredTransferJob gets at any time the 302 error code? something like it tries again with the correct url?

I continued debugging, and it turns out that KIO::StoredTransferJob does try to follow the redirection (SimpleJob::isRedirectionHandlingEnabled() returns true). However, the url returned by Zimbra is:
https://<front server>/dav/<user email>/Calendar/b82c02c5-60e3-4f47-8ca0-e4e2d7a799e0.ics
while the initial url set by DavItemCreateJob is:
https://<username>@<front server>/dav/<user email>/Calendar/1412589498.R931.ics
(I checked that by disabling the internal redirection handling).

It seems that the missing <username> in the redirected url triggers a 401 error by Zimbra. What do you think?

I turns out that the username is correctly added by KIO::StoredTransferJob.

I modified resources/dav/common/davutils.cpp, DavUtils::createDavItem to be specific, to use the uid of the event instead of unique id created by DavUtils::createUniqueId(), as expected by Zimbra. This modification made the creation of the event possible (I can provide a patch if necessary, but it's three simple lines of code).

However, I managed to solve the issue of the redirection. The actual bug seems that KIO::StoredTransferJob correctly copy the username from the original url to the redirected one, but not the password (at least, it is my understanding of the bug). What I did is in the presence of a redirection (code 302 here), I create a second DavItemCreateJob. Its result signal is connected to a new slot that updates the variable mItem. I give the second job the same item (with the new url), and the correct url (with username and password).

This solution is not perfect since it can infinitely redirect (contrary to KIO::StoredTransferJob which has a hardcoded limit of 5 redirection before failing), and at the moment, only the 302 HTTP code is handled (but other codes are easy to handle I guess). Also, I'm not sure what happens if one of the DavItemCreateJob fails...

Created attachment 88997 [details]
Patch to handle redirections in CalDAV event creations

Wow, thanks for the hard work!

I'll have a look at your patch, but the possibility of endless redirections is making me a bit uneasy.

Cheers,
Grégory

Git commit fe41e44e0424c8a2d229763dea6636ee2bbdd0a1 by Grégory Oestreicher.
Committed on 09/10/2014 at 16:42.
Pushed by goestreicher into branch 'KDE/4.14'.

Manually follow redirect when creating items

Needed for at least Zimbra that doesn't like
having items files named by anything else but
the incidence UID and that redirects. KIO
does not supply the username / password (as
it should), but we have no way to ask the user
for confirmation.

Many thanks to Benjamin Girault for the initial
debug, patch and testing.

M  +25   -5    resources/dav/common/davitemcreatejob.cpp
M  +1    -0    resources/dav/common/davitemcreatejob.h

http://commits.kde.org/kdepim-runtime/fe41e44e0424c8a2d229763dea6636ee2bbdd0a1