GNOME Bugzilla – Bug 623066
CalDAV doesn't read Location header from Created response
Last modified: 2014-02-25 13:49:29 UTC
Created attachment 164836 [details] [review] Fix redirect status check in caldav According to the RFC2616 "Location" response header must be process also on 201. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 Here is a patch that fixes the issue.
Any news?
up
When I create an event with 2.30.1.2 to my groupware server (which typically responds to PUT requests with a 301 to a new location) it looks to me like Evolution follows that redirect. --- localhost.localdomain - - [12/Sep/2010 20:44:08] "PUT /dav/Calendar/Overview/20100913T004404Z-3534-100-1-0_linux-yu4c.site-20100913T004408Z.ics HTTP/1.1" 401 - localhost.localdomain - - [12/Sep/2010 20:44:09] "PUT /dav/Calendar/Overview/20100913T004404Z-3534-100-1-0_linux-yu4c.site-20100913T004408Z.ics HTTP/1.1" 201 - localhost.localdomain - - [12/Sep/2010 20:44:10] "GET /dav/Calendar/Overview/20100913T004404Z-3534-100-1-0_linux-yu4c.site-20100913T004408Z.ics HTTP/1.1" 301 - localhost.localdomain - - [12/Sep/2010 20:44:10] "GET /dav/Calendar/20100913T004404Z-3534-100-1-0_linux-yu4c.site-20100913T004408Z.ics HTTP/1.1" 401 - localhost.localdomain - - [12/Sep/2010 20:44:10] "GET /dav/Calendar/20100913T004404Z-3534-100-1-0_linux-yu4c.site-20100913T004408Z.ics HTTP/1.1" 200 - --- I'll check if it does this if the intial PUT response contains a Location header (which I think currently I disable via user-agent detection).
Nope. Evolution ignores a Location header in the 201 PUT response. PUT /dav/Calendar/Overview/20100913T004755Z-3534-100-1-1_linux-yu4c.site-20100913T004820Z.ics HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Evolution/2.30.1 If-None-Match: * Content-Type: text/calendar; charset=utf-8 Authorization: Basic YWRhbTpmcmVkMTIz Content-Length: 1001 BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:/freeassociation.sourceforge.net/Tzfile/America/Detroit X-LIC-LOCATION:America/Detroit BEGIN:STANDARD TZNAME:EST DTSTART:19701107T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT TZNAME:EDT DTSTART:19700314T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20100913T004755Z-3534-100-1-1@linux-yu4c.site DTSTAMP:20100913T004755Z DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/America/Detroit: 20100909T103000 DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/America/Detroit: 20100909T110000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:qeqew LOCATION:qweqwe DESCRIPTION:qeqweqe CATEGORIES:Hot Contacts\,Holiday Cards CLASS:PUBLIC CREATED:20100913T004820Z LAST-MODIFIED:20100913T004820Z END:VEVENT END:VCALENDAR HTTP/1.0 201 Created Server: BaseHTTP/0.3 Python/2.6.5 Date: Mon, 13 Sep 2010 00:48:20 GMT Etag: 15572690:1 Location: /dav/Calendar/20100913T004755Z-3534-100-1-1_linux-yu4c.site-20100913T004820Z.ics GET /dav/Calendar/Overview/20100913T004755Z-3534-100-1-1_linux-yu4c.site-20100913T004820Z.ics HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Evolution/2.30.1 Authorization: Basic YWRhbTpmcmVkMTIz HTTP/1.0 301 Moved Server: BaseHTTP/0.3 Python/2.6.5 Date: Mon, 13 Sep 2010 00:48:20 GMT Location: /dav/Calendar/20100913T004755Z-3534-100-1-1_linux-yu4c.site-20100913T004820Z.ics GET /dav/Calendar/20100913T004755Z-3534-100-1-1_linux-yu4c.site-20100913T004820Z.ics HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Evolution/2.30.1 Authorization: Basic YWRhbTpmcmVkMTIz HTTP/1.0 200 OK Server: BaseHTTP/0.3 Python/2.6.5 Date: Mon, 13 Sep 2010 00:48:21 GMT Content-Length: 579 etag: 15572690:1 Content-Type: text/calendar BEGIN:VCALENDAR VERSION:2.0 ....
Is there anybody to apply the patch? What can I do to get this patch in the tree?
Is it possible to apply this patch? Thanks.
Any news on this issue?
I do not think the patch is correct, because it also resubmits the message to the new location, which is wrong, based on the information in your link from comment #0, where is written that for 201 the Location contains place where the event was actually stored, not where you should write it again.
Comment#9 +1 Resubmission is incorrect; the Location header just specifies the actual location of the resouce (typically this is in the same collection but under a different reference as the server needed to rename it for some reason).
Created attachment 213271 [details] [review] proposed eds patch for evolution-data-server; This only enhances Cédric's patch for that simple check, it doesn't bring anything new here (I'll still add credits to Cédric), but I cannot test it, none of my 4 servers return Location header on the Created response. Adam, are you able to test it, please? I think you'll not find any difference from the UI, only with logging, because if I read your above log properly then the server redirects on the following GET request to the right place, thus it handles the issue at the background, only with repeated requests done from evoltuion.
Adam, Ping. FWIW: Tryton seems to use that header. I just heard of it myself.
I found out that a Google server also returns "Location" for "201 Created" responses, but it doesn't set "ETag" header (Adam's server returns both ETag and Location headers), which led me in the code to a closer place for the change, thus I fixed this in a completely different way finally, with: Created commit e9c3087 in eds master (3.11.91+) [1] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=e9c3087