GNOME Bugzilla – Bug 673538
Malformed Google Calendar URLs passed by e-cal-backend-caldav.c
Last modified: 2012-04-16 07:38:11 UTC
URIs used to create appointments seem to work however when trying to retrieve the posted appointment, the URL posted doesn't seem to work. This patch seems to help though probably not the right long term solution in e-cal-backend-caldav.c. There seems to be 2 problems: 1) the URL doesn't work is the "@" sign is replaced by an "_" for the username. 2) the URL doesn't work when the timestamp is added evolution-data-server-3.2.3/calendar/backends/caldav diff -uNr e-cal-backend-caldav.c-orig e-cal-backend-caldav.c --- e-cal-backend-caldav.c-orig 2012-04-04 16:36:27.542037970 -0700 +++ e-cal-backend-caldav.c 2012-04-04 16:37:09.718038319 -0700 @@ -481,14 +481,14 @@ tmp = isodate_from_time_t (time (NULL)); /* quite long, but ensures uniqueness quite well, without using UUIDs */ - href = g_strconcat (uid ? uid : "no-uid", tmp ? "-" : "", tmp ? tmp : "", ".ics", NULL); + href = g_strconcat (uid ? uid : "no-uid", ".ics", NULL); g_free (tmp); g_free (uid); icomp_x_prop_set (icomp, X_E_CALDAV "HREF", href); - return g_strdelimit (href, " /'\"`&();|<>$%{}!\\:*?#@", '_'); + return g_strdelimit (href, " /'\"`&();|<>$%{}!\\:*?#", '_'); } /* ensure etag is quoted (to workaround potential server bugs) */
This is a really crude patch but it seems to work for Philippe Kalaf and I. Changing the "@" seems to confuse the Google Calendar servers.
Don't we lose uniqueness if we remove tmp?
I have tested this for a few days and haven't run into any issues. The last use "tmp" in the href generation seemed to me was there to avoid browser interference (and web caching issues). But it doesn't help in the uniqueness of the calendar object itself. Could be wrong of course but that seems to fix it for me. It's possible that something else as changed on the URL handling on the Google servers side and a better fixed could be implemented to produce a href that more closely match the servers' expectations.
Thanks for a bug report. I made more complicated patch in bug #673894, and committed it to sources. See the bug for more detailed information, but as a summary: I think that Google updated their CalDAV server and broke some functionality. *** This bug has been marked as a duplicate of bug 673894 ***
(In reply to comment #4) > Thanks for a bug report. I made more complicated patch in bug #673894, and > committed it to sources. Thanks. I tried to backport your patch to 3.2.3 but I can't seem to find update_slave_cmd() declared anywhere in 3.2.3+ or 3.4. I altered the patch to remove it but it still seg faults elsewhere. I ran a few tests and it would seem that the url we pass would fail 100% of the time with the Google Calendar servers.
(In reply to comment #5) > (In reply to comment #4) > > Thanks for a bug report. I made more complicated patch in bug #673894, and > > committed it to sources. > > Thanks. I tried to backport your patch to 3.2.3 but I can't seem to find > update_slave_cmd() declared anywhere in 3.2.3+ or 3.4. It's only a simple function, see here: http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/caldav/e-cal-backend-caldav.c#n314 you can replace that call with cbdav->priv->slave_cmd = SLAVE_SHOULD_WORK; but you cannot remove it. > I altered the patch to remove it but it still seg faults elsewhere. Could you make the change I suggest above and retest, please? And if it'll crash for you, then could you paste here the backtrace of the crash? The best if you could add also the patch you altered here, thus I will have an idea of the exact code change. > I ran a few tests and it would seem that the url we pass would fail 100% of > the time with the Google Calendar servers. Pass URL where, into the PUT request or the GET request? I tested the patch on 3.4.0 (actually git master, but that's the same for CalDAV) and I was able to create an item, edit the item and delete it as well - all was properly propagated into Google server (I checked with their web UI) and I had no crash. Maybe the code is slightly different in CalDAV for 3.2.x, thus it causes the crash?
Sorry for being misleading: short memory, I forgot there was another issue in 3.2.3. I extracted a fresh tarball to start clean and forgot I needed to apply this: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Initialize-dbus-glib-threading.patch;att=1;bug=666890 Your patch worked in valgrind which is what reminded me of the initialization issue. Using "cbdav->priv->slave_cmd = SLAVE_SHOULD_WORK;" is exactly what I had done. So with both patches (and the one line change): it works. It is slower because it has to fail every time and re-issue the http request. Since we know the Google Calendar behavior has change, could we maybe try the new URL first?
Good it works for you too. There are some tweaks for Google server already, that's true, but I would like to keep them as low as possible, because this is a generic CalDAV backend, not a Google backend. Furthermore, Google does things wrong, not evolution's backend.