GNOME Bugzilla – Bug 349573
evolution erroneously sends If-None-Match header when using caldav to DELETE an event
Last modified: 2006-12-07 21:42:57 UTC
Please describe the problem: i am a developer for cosmo, a caldav server. some of our users have reported that evolution 2.6 is unable to delete events from their caldav calendars. it appears that when evolution sends a DELETE for an event resource, it includes an If-None-Match header. taken from an example request trace: DELETE /cosmo/home/lcd/Scooby/20060421T005015Z.ics HTTP/1.1 Host: 127.0.0.1:8080 If-None-Match: "944-1145580615365" Authorization: Basic bGNkOnNleHNleA== User-Agent: Evolution/1.6.1 (i dunno what's up with that User-Agent header. i didn't get this trace output myself. the user says he's using evolution 2.6.) as per the HTTP spec, cosmo matches the etag specified in the If-None-Match header to the current etag of the resource in question. when it finds that the etags match, it returns a 412 (precondition failed). to the user, the delete operation apparently just doesn't seem to work. i can't think of a reason that evolution should provide If-None-Match when deleting an event, and i can't think of a reasonable way to work around the issue in cosmo. i believe cosmo is doing the right thing. i don't have a linux box with a head on it, so i can't directly observe the issue. the associated cosmo bug is at <https://bugzilla.osafoundation.org/show_bug.cgi?id=5746>. Steps to reproduce: 1. access a calendar on a cosmo server (or presumably any caldav server) 2. attempt to delete an event Actual results: unknown, as i don't have the hardware to test the problem directly. the person who reported the cosmo bug simply said "can't delete an event with evolution". Expected results: Does this happen every time? apparently so. Other information:
Yeah I am not able to delete any event addded in evolution. Here is the header sent by my evolution: DELETE /cosmo/home/testdump/20060801T183256Z.ics HTTP/1.1 Host: localhost:8080 If-None-Match: "965-1154457177041" Authorization: Basic dGVzdGR1bXA6dGVzdDEyMw== User-Agent: Evolution/1.6.1 My evolution version is 2.6.1 as part of the Ubuntu and I am using Cosmo (http://cosmo.osafoundation.org/) as the Caldav server. I wonder why evolution sends 1.6.1 - guess it needs to change the major version to 2 somewhere.
Here is the relevant excerpt from RFC2068, so Evolution is clearly getting this wrong. It should be sending that ETag through in an "If-match" header instead. 14.26 If-None-Match The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of a resource which was not known to exist. As a special case, the value "*" matches any current entity of the resource. If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method. Instead, if the request method was GET or HEAD, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related entity-header fields (particularly ETag) of one of the entities that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed). A patch would seem to be trivial. This is an example, against evolution-data-server 1.6.3: diff --git a/calendar/backends/caldav/e-cal-backend-caldav.c b/calendar/backends/caldav/e-cal-backend-caldav.c index d7049a4..db8f404 100644 --- a/calendar/backends/caldav/e-cal-backend-caldav.c +++ b/calendar/backends/caldav/e-cal-backend-caldav.c @@ -1040,7 +1040,7 @@ caldav_server_delete_object (ECalBackend if (object->etag != NULL) { soup_message_add_header (message->request_headers, - "If-None-Match", object->etag); + "If-Match", object->etag); } d(setup_debug (message);)
This is such a trivial fix, to a problem that makes CalDAV a lot less useful in the real world (i.e. can't delete events from a compliant CalDAV server). Can someone with authority review it and get it into the trunk? Thanks, Andrew McMillan.
Yepp, this patch looks good to me! If you have cvs commit rights, please go ahead and commit it (including a ChangeLog entry).
I work with Andrew M and have commit rights, so have committed the patch for him.
Confirming that this is in CVS, shouldn't the bug be marked as "fixed"?
Agreed, I would have marked it as "fixed", but I can't change the status. Darn... Unless I'm being dense, and can actually change the status... Could someone with the appropriate access please do this?
Even though this is now in EDS 1.9.3, I'm interested to see that my ChangeLog entry was removed, and the fixed bug number wasn't mentioned in the NEWS file (although my name is)...
Andrew: It seems like you comitted the ChangeLog entry to the wrong file: http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/ChangeLog?rev=1.625&view=log
(In reply to comment #9) > Andrew: It seems like you comitted the ChangeLog entry to the wrong file: Oops, so has been...