After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 623066 - CalDAV doesn't read Location header from Created response
CalDAV doesn't read Location header from Created response
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
2.30.x (obsolete)
Other All
: Normal major
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav]
Depends on:
Blocks:
 
 
Reported: 2010-06-28 19:42 UTC by Cédric Krier
Modified: 2014-02-25 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix redirect status check in caldav (717 bytes, patch)
2010-06-28 19:42 UTC, Cédric Krier
reviewed Details | Review
proposed eds patch (1.06 KB, patch)
2012-05-02 11:28 UTC, Milan Crha
none Details | Review

Description Cédric Krier 2010-06-28 19:42: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.
Comment 1 Cédric Krier 2010-07-14 22:03:34 UTC
Any news?
Comment 2 Cédric Krier 2010-08-19 21:25:25 UTC
up
Comment 3 awilliam 2010-09-13 00:49:32 UTC
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).
Comment 4 awilliam 2010-09-13 00:54:21 UTC
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
....
Comment 5 Cédric Krier 2011-01-10 15:14:54 UTC
Is there anybody to apply the patch?
What can I do to get this patch in the tree?
Comment 6 Cédric Krier 2011-02-23 23:23:48 UTC
up
Comment 7 Cédric Krier 2011-09-30 19:26:30 UTC
Is it possible to apply this patch?

Thanks.
Comment 8 Cédric Krier 2012-01-27 19:26:44 UTC
Any news on this issue?
Comment 9 Milan Crha 2012-05-02 10:35:04 UTC
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 10 awilliam 2012-05-02 10:46:35 UTC
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).
Comment 11 Milan Crha 2012-05-02 11:28:32 UTC
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.
Comment 12 Tobias Mueller 2013-04-08 15:50:25 UTC
Adam, Ping.

FWIW: Tryton seems to use that header. I just heard of it myself.
Comment 13 Milan Crha 2014-02-25 13:47:51 UTC
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