Created attachment 160875 [details]
Backtrace while waiting

We are using Evolution 2.28 from Debian Squeeze on Debian Lenny with KDE 3.5.10 as the Desktop Environment.  Evolution has been patched and repackaged with patches from bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=566330
https://bugzilla.gnome.org/show_bug.cgi?id=604650

The backend is Zimbra 6.0.6 with all latest patches running on CentOS 5.4 and the calendar is of type CALDAV.

The desired task is to create a new appointment.  The expected behavior is successful creation of new appointments with nearly immediate return of application control to the user.

Instead, 100% of the time we see Zimbra immediately create the appointment but there is a 75 second delay before control is returned to the user.

Here is what we had posted to the Evolution mailing list:

"It seems like the overall process is Evolution sends a DAV PUT, Zimbra
replies with a redirect to a more accurate (?) URI.  Evolution does a
DAV PUT to this URI.  Zimbra creates the appointment.  75 second delay.
Evolution does a DAV GET for the appointment (I assume to verify it has
been created).  Evolution returns control to the user."

"We have traced the packet exchange simultaneously from both Zimbra and
Evolution.  There are no dropped packets.  We see the same thing on both
sides.  Zimbra responds with a 201 created message indicating it has
added the appointment and Evolution ACKs the packet.  Then everyone
waits.  75 seconds later, Zimbra sends a FIN packet to close the
connection.  After the connection closes, Evolution sends the DAV GET,
Zibmra responds, and all is good."

"Either Zimbra is sitting around for 75 seconds doing nothing or Zimbra
has realized there has been no traffic on the TCP connection and
initiates a close after a timeout period.  I think the latter is more
likely and would indicate a bug in Evolution where it does not close the
initial session once the DAV PUT is successful.  If we could get it to
close the session, it could then continue with the DAV GET and creation
would appear to be almost instantaneous."

Milan Crha commented that this behavior was only seen with Zimbra so it may be a Zimbra issue or it may just be a difference in expectations.  Perhaps the other solution assume they are supposed to close the connection whereas Zimbra assumes the client is supposed to close the connection.

I will attach a packet trace and two back traces.  bt is a backtrace taken while Evolution was waiting.  bt.finished was taken after control returned to the user interface.