maryjane
/
syncevolution
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
syncevolution/src/backends/webdav/WebDAVSource.cpp

650 lines
25 KiB
C++
Raw Normal View History

WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
/*
* Copyright (C) 2010 Intel Corporation
*/
#include "WebDAVSource.h"
#ifdef ENABLE_DAV
WebDAVSource: debug dump of properties This verifies that reading properties works. For Google, the real calendar collection happens to be ../events/.
2010-10-05 13:17:06 +02:00
#include <boost/bind.hpp>
#include <boost/algorithm/string/replace.hpp>
properly resolve relative ../events/ path for Google Added URI::resolve(), which is now used for Google default calendar if (and only if) starting with the "/user" or "/user/" URL.
2010-10-05 14:48:59 +02:00
#include <boost/algorithm/string/predicate.hpp>
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
#include <boost/algorithm/string/classification.hpp>
WebDAVSource: debug dump of properties This verifies that reading properties works. For Google, the real calendar collection happens to be ../events/.
2010-10-05 13:17:06 +02:00
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
SE_BEGIN_CXX
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
/**
* Retrieve settings from SyncConfig.
* NULL pointer for config is allowed.
*/
class ContextSettings : public Neon::Settings {
boost::shared_ptr<const SyncConfig> m_context;
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
std::string m_url;
bool m_googleUpdateHack;
bool m_googleChildHack;
CalDAV: added Google Calendar alarm hack Google Calendar adds a VALARM when a VEVENT is created for the first time on the server via CalDAV. This is not what we want, if the VEVENT had no VALARM, that's how it should be stored. As a workaround we detect this special case (new VEVENT without VALARM) and send the original data again. Having to resend with higher SEQUENCE and LAST-MODIFIED/DTSTAMP values makes this a bit complex and slow, because we need to get the actual data from the server (cannot guess what time stamps were assigned). This leads to an interesting question: if the clock on the local side is unsynchronized, its LAST-MODIFIED time stamps might end up being lower than the values on the server, which prevents sending local updates. There's currently no solution for this in the backend.
2010-11-30 17:45:40 +01:00
bool m_googleAlarmHack;
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
public:
ContextSettings(const boost::shared_ptr<const SyncConfig> &context) :
CalDAV: added Google Calendar alarm hack Google Calendar adds a VALARM when a VEVENT is created for the first time on the server via CalDAV. This is not what we want, if the VEVENT had no VALARM, that's how it should be stored. As a workaround we detect this special case (new VEVENT without VALARM) and send the original data again. Having to resend with higher SEQUENCE and LAST-MODIFIED/DTSTAMP values makes this a bit complex and slow, because we need to get the actual data from the server (cannot guess what time stamps were assigned). This leads to an interesting question: if the clock on the local side is unsynchronized, its LAST-MODIFIED time stamps might end up being lower than the values on the server, which prevents sending local updates. There's currently no solution for this in the backend.
2010-11-30 17:45:40 +01:00
m_context(context),
m_googleUpdateHack(false),
m_googleChildHack(false),
m_googleAlarmHack(false)
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
{
if (m_context) {
vector<string> urls = m_context->getSyncURL();
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
if (!urls.empty()) {
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
m_url = urls.front();
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
std::string username = m_context->getUsername();
WebDAV: escape username before adding it to syncURL The username might contain special characters. It must be escaped before adding it to the URL. Found when the code was used with an the default "Your SyncML Username" username string.
2010-11-10 15:22:19 +01:00
boost::replace_all(m_url, "%u", Neon::URI::escape(username));
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
}
Neon::URI uri = Neon::URI::parse(m_url);
typedef boost::split_iterator<string::iterator> string_split_iterator;
for (string_split_iterator arg =
boost::make_split_iterator(uri.m_query, boost::first_finder("&", boost::is_iequal()));
arg != string_split_iterator();
++arg) {
static const std::string keyword = "SyncEvolution=";
if (boost::istarts_with(*arg, keyword)) {
std::string params(arg->begin() + keyword.size(), arg->end());
for (string_split_iterator flag =
boost::make_split_iterator(params,
boost::first_finder(",", boost::is_iequal()));
flag != string_split_iterator();
++flag) {
if (boost::iequals(*flag, "UpdateHack")) {
m_googleUpdateHack = true;
} else if (boost::iequals(*flag, "ChildHack")) {
m_googleChildHack = true;
CalDAV: added Google Calendar alarm hack Google Calendar adds a VALARM when a VEVENT is created for the first time on the server via CalDAV. This is not what we want, if the VEVENT had no VALARM, that's how it should be stored. As a workaround we detect this special case (new VEVENT without VALARM) and send the original data again. Having to resend with higher SEQUENCE and LAST-MODIFIED/DTSTAMP values makes this a bit complex and slow, because we need to get the actual data from the server (cannot guess what time stamps were assigned). This leads to an interesting question: if the clock on the local side is unsynchronized, its LAST-MODIFIED time stamps might end up being lower than the values on the server, which prevents sending local updates. There's currently no solution for this in the backend.
2010-11-30 17:45:40 +01:00
} else if (boost::iequals(*flag, "AlarmHack")) {
m_googleAlarmHack = true;
} else if (boost::iequals(*flag, "Google")) {
m_googleUpdateHack =
m_googleChildHack =
m_googleAlarmHack = true;
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
} else {
SE_THROW(StringPrintf("unknown SyncEvolution flag %s in URL %s",
std::string(flag->begin(), flag->end()).c_str(),
m_url.c_str()));
}
}
} else {
SE_THROW(StringPrintf("unknown parameter %s in URL %s",
std::string(arg->begin(), arg->end()).c_str(),
m_url.c_str()));
}
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
}
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
}
}
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
virtual std::string getURL() { return m_url; }
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
virtual bool verifySSLHost()
{
return !m_context || m_context->getSSLVerifyHost();
}
virtual bool verifySSLCertificate()
{
return !m_context || m_context->getSSLVerifyServer();
}
proxy settings: transfer to neon If proxy settings are turned off in the config, the default system proxy settings are used. This depends on ne_session_system_proxy(), introduced in neon 0.29. The version is checked at configure time. A fallback if only an older version is found is intentionally not present yet, the feature is meant to work in all cases.
2010-11-22 14:52:34 +01:00
virtual std::string proxy()
{
if (!m_context ||
!m_context->getUseProxy()) {
return "";
} else {
return m_context->getProxyHost();
}
}
CalDAV: added Google Calendar alarm hack Google Calendar adds a VALARM when a VEVENT is created for the first time on the server via CalDAV. This is not what we want, if the VEVENT had no VALARM, that's how it should be stored. As a workaround we detect this special case (new VEVENT without VALARM) and send the original data again. Having to resend with higher SEQUENCE and LAST-MODIFIED/DTSTAMP values makes this a bit complex and slow, because we need to get the actual data from the server (cannot guess what time stamps were assigned). This leads to an interesting question: if the clock on the local side is unsynchronized, its LAST-MODIFIED time stamps might end up being lower than the values on the server, which prevents sending local updates. There's currently no solution for this in the backend.
2010-11-30 17:45:40 +01:00
virtual bool googleUpdateHack() const { return m_googleUpdateHack; }
virtual bool googleChildHack() const { return m_googleChildHack; }
virtual bool googleAlarmHack() const { return m_googleChildHack; }
CalDAV: make Google hacks configurable Yahoo works without any of the Google specific hacks. Because these have side effects (performance, change data), they shouldn't be used when talking to other CalDAV servers. This patch adds a "SyncEvolution" URL parameter with a comma separated list of flags: "UpdateHack" = increase SEQUENCE and LAST-MODIFIED "ChildHack" = replace RECURRENCE-ID in stand-alone child events This needs to be appended to the syncURL, like this: syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=UpdateHack,ChildHack The reason for using "SyncEvolution" here is that other parameters might one day be passed through to the underlying server; at the moment, anything other than "SyncEvolution" causes an error. They need to specified explicitly. Hard-coding a check for www.google.com did not feel right.
2010-11-10 10:06:07 +01:00
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
virtual void getCredentials(const std::string &realm,
std::string &username,
std::string &password)
{
if (m_context) {
username = m_context->getUsername();
password = m_context->getPassword();
}
}
virtual int logLevel()
{
return m_context ?
m_context->getLogLevel() :
0;
}
};
WebDAV: first version which can log into Google The Neon::Session wraps most of the relevant calls. It is parameterized by Neon::Settings. It is uncertain where all of these are meant to come from, because there is no peer configuration in many cases. Perhaps we can enforce that a WebDAV source may only be created in a context which has one and exactly one peer config? The current intermediate solution in WebDAVSourceRegister.cpp grabs all settings from WEBDAV_* env variables. Disabling SSL verification and Neon debug logging are implemented. Opening the source runs a few checks on the URL. Disabling SSL certificate checking turned out to be necessary, probably because of the known issue of gnutls not trusting the weak Google certificate chain.
2010-10-05 11:02:33 +02:00
WebDAVSource::WebDAVSource(const SyncSourceParams &params,
const boost::shared_ptr<Neon::Settings> &settings) :
TrackingSyncSource(params),
m_settings(settings)
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
{
WebDAV settings: take from context This replaces the WEBDAV_* env variables with access to the normal per-peer properties, passed into the source via the new SyncSourceParams context member. When used on the command line, @foobar context configs are not enough to use the WebDAV sources. A properly configured peer context (foo@bar) is needed. There is no explicit check for this, the resulting error is about not being able to access the empty URL `' (Neon uses these quotation marks).
2010-10-08 15:10:40 +02:00
if (!m_settings) {
m_settings.reset(new ContextSettings(params.m_context));
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
void WebDAVSource::open()
{
WebDAV: first version which can log into Google The Neon::Session wraps most of the relevant calls. It is parameterized by Neon::Settings. It is uncertain where all of these are meant to come from, because there is no peer configuration in many cases. Perhaps we can enforce that a WebDAV source may only be created in a context which has one and exactly one peer config? The current intermediate solution in WebDAVSourceRegister.cpp grabs all settings from WEBDAV_* env variables. Disabling SSL verification and Neon debug logging are implemented. Opening the source runs a few checks on the URL. Disabling SSL certificate checking turned out to be necessary, probably because of the known issue of gnutls not trusting the weak Google certificate chain.
2010-10-05 11:02:33 +02:00
SE_LOG_DEBUG(NULL, NULL, "using libneon %s with %s",
ne_version_string(), Neon::features().c_str());
Neon C++: cache Session Starting a neon Session is slow, in particular when libproxy is involved (seems to search for proxy servers, which involves a DNS timeout when none are around). Another delay is opening the TCP connection and determining which kind of autentication is needed. For a normal program run there's not much that can be done to speed this up, but in client-test it helps a lot to reuse an existing Session instance between different tests. This patch enables that by keeping one Session instance around and returning that if the new one has the same parameters. The Settings pointer is a boost::shared_ptr, but this patch avoids using it unless the Session is in active use, just in case that a user wants to merge the settings into a class with a different life time.
2010-11-30 17:35:53 +01:00
m_session = Neon::Session::create(m_settings);
WebDAV: first version which can log into Google The Neon::Session wraps most of the relevant calls. It is parameterized by Neon::Settings. It is uncertain where all of these are meant to come from, because there is no peer configuration in many cases. Perhaps we can enforce that a WebDAV source may only be created in a context which has one and exactly one peer config? The current intermediate solution in WebDAVSourceRegister.cpp grabs all settings from WEBDAV_* env variables. Disabling SSL verification and Neon debug logging are implemented. Opening the source runs a few checks on the URL. Disabling SSL certificate checking turned out to be necessary, probably because of the known issue of gnutls not trusting the weak Google certificate chain.
2010-10-05 11:02:33 +02:00
// Start by checking server capabilities.
// Verifies URL.
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
SE_LOG_DEBUG(NULL, NULL, "read capabilities of %s",
m_session->getURI().toURL().c_str());
WebDAV: first version which can log into Google The Neon::Session wraps most of the relevant calls. It is parameterized by Neon::Settings. It is uncertain where all of these are meant to come from, because there is no peer configuration in many cases. Perhaps we can enforce that a WebDAV source may only be created in a context which has one and exactly one peer config? The current intermediate solution in WebDAVSourceRegister.cpp grabs all settings from WEBDAV_* env variables. Disabling SSL verification and Neon debug logging are implemented. Opening the source runs a few checks on the URL. Disabling SSL certificate checking turned out to be necessary, probably because of the known issue of gnutls not trusting the weak Google certificate chain.
2010-10-05 11:02:33 +02:00
int caps = m_session->options();
static const Flag descr[] = {
{ NE_CAP_DAV_CLASS1, "Class 1 WebDAV (RFC 2518)" },
{ NE_CAP_DAV_CLASS2, "Class 2 WebDAV (RFC 2518)" },
{ NE_CAP_DAV_CLASS3, "Class 3 WebDAV (RFC 4918)" },
{ NE_CAP_MODDAV_EXEC, "mod_dav 'executable' property" },
{ NE_CAP_DAV_ACL, "WebDAV ACL (RFC 3744)" },
{ NE_CAP_VER_CONTROL, "DeltaV version-control" },
{ NE_CAP_CO_IN_PLACE, "DeltaV checkout-in-place" },
{ NE_CAP_VER_HISTORY, "DeltaV version-history" },
{ NE_CAP_WORKSPACE, "DeltaV workspace" },
{ NE_CAP_UPDATE, "DeltaV update" },
{ NE_CAP_LABEL, "DeltaV label" },
{ NE_CAP_WORK_RESOURCE, "DeltaV working-resouce" },
{ NE_CAP_MERGE, "DeltaV merge" },
{ NE_CAP_BASELINE, "DeltaV baseline" },
{ NE_CAP_ACTIVITY, "DeltaV activity" },
{ NE_CAP_VC_COLLECTION, "DeltaV version-controlled-collection" },
{ 0, NULL }
};
SE_LOG_DEBUG(NULL, NULL, "%s WebDAV capabilities: %s",
m_session->getURL().c_str(),
Flags2String(caps, descr).c_str());
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// Find default calendar. Same for address book, with slightly
// different parameters.
WebDAVSource: debug dump of properties This verifies that reading properties works. For Google, the real calendar collection happens to be ../events/.
2010-10-05 13:17:06 +02:00
//
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
// Stops when:
// - current path is calendar collection (= contains VEVENTs)
// Gives up:
// - when running in circles
// - nothing else to try out
// - tried 10 times
// Follows:
// - CalDAV calendar-home-set (assumed to be on same server)
// - collections
//
// TODO: support more than one calendar. Instead of stopping at the first one,
// scan more throroughly, then decide deterministically.
int counter = 0;
const int limit = 10;
std::set<std::string> tried;
std::set<std::string> candidates;
std::string path = m_session->getURI().m_path;
WebDAVSource: avoid cut-and-paste of boost::bind The boost::bind() calls is complex enought to only write it once...
2010-10-05 14:24:16 +02:00
Neon::Session::PropfindPropCallback_t callback =
boost::bind(&WebDAVSource::openPropCallback,
this, _1, _2, _3, _4);
WebDAVSource: debug dump of properties This verifies that reading properties works. For Google, the real calendar collection happens to be ../events/.
2010-10-05 13:17:06 +02:00
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
while (true) {
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// must normalize so that we can compare against results from server
path = Neon::URI::normalizePath(path, true);
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
SE_LOG_DEBUG(NULL, NULL, "testing %s", path.c_str());
tried.insert(path);
// Property queries also checks credentials because typically
// the properties are protected.
//
// First dump WebDAV "allprops" properties (does not contain
// properties which must be asked for explicitly!). Only
// relevant for debugging.
if (LoggerBase::instance().getLevel() >= Logger::DEV) {
SE_LOG_DEBUG(NULL, NULL, "read all WebDAV properties of %s", path.c_str());
Neon::Session::PropfindPropCallback_t callback =
boost::bind(&WebDAVSource::openPropCallback,
this, _1, _2, _3, _4);
m_session->propfindProp(path, 0, NULL, callback);
}
// Now ask for some specific properties of interest for us.
// Using CALDAV:allprop would be nice, but doesn't seem to
// be possible with Neon.
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
m_davProps.clear();
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
static const ne_propname caldav[] = {
// WebDAV ACL
{ "DAV:", "alternate-URI-set" },
{ "DAV:", "principal-URL" },
{ "DAV:", "group-member-set" },
{ "DAV:", "group-membership" },
{ "DAV:", "displayname" },
{ "DAV:", "resourcetype" },
// CalDAV
{ "urn:ietf:params:xml:ns:caldav", "calendar-home-set" },
{ "urn:ietf:params:xml:ns:caldav", "calendar-description" },
{ "urn:ietf:params:xml:ns:caldav", "calendar-timezone" },
{ "urn:ietf:params:xml:ns:caldav", "supported-calendar-component-set" },
{ "urn:ietf:params:xml:ns:caldav", "supported-calendar-data" },
{ "urn:ietf:params:xml:ns:caldav", "max-resource-size" },
{ "urn:ietf:params:xml:ns:caldav", "min-date-time" },
{ "urn:ietf:params:xml:ns:caldav", "max-date-time" },
{ "urn:ietf:params:xml:ns:caldav", "max-instances" },
{ "urn:ietf:params:xml:ns:caldav", "max-attendees-per-instance" },
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// CardDAV
{ "urn:ietf:params:xml:ns:carddav", "addressbook-home-set" },
{ "urn:ietf:params:xml:ns:carddav", "principal-address" },
{ "urn:ietf:params:xml:ns:carddav", "addressbook-description" },
{ "urn:ietf:params:xml:ns:carddav", "supported-address-data" },
{ "urn:ietf:params:xml:ns:carddav", "max-resource-size" },
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
{ NULL, NULL }
};
m_session->propfindProp(path, 0, caldav, callback);
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
StringMap &props = m_davProps[path];
if (typeMatches(props)) {
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
// found it
break;
}
// find next path
static const std::string hrefStart = "<DAV:href>";
static const std::string hrefEnd = "</DAV:href";
std::string next;
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
const std::string &home = props[homeSetProp()];
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
if (!home.empty()) {
size_t start = home.find(hrefStart);
if (start != home.npos) {
size_t end = home.find(hrefEnd, start);
if (end != home.npos) {
start += hrefStart.size();
next = home.substr(start, end - start);
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
SE_LOG_DEBUG(NULL, NULL, "follow home-set property to %s", next.c_str());
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
}
}
}
if (next.empty()) {
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
const std::string &type = props["DAV::resourcetype"];
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
if (type.find("<DAV:collection></DAV:collection>") != type.npos) {
// List members and find new candidates.
// Yahoo! Calendar does not return resources contained in /dav/<user>/Calendar/
// if <allprops> is used. Properties must be requested explicitly.
SE_LOG_DEBUG(NULL, NULL, "list items in %s", path.c_str());
static const ne_propname props[] = {
{ "DAV:", "displayname" },
{ "DAV:", "resourcetype" },
{ "urn:ietf:params:xml:ns:caldav", "calendar-home-set" },
{ "urn:ietf:params:xml:ns:caldav", "calendar-description" },
{ "urn:ietf:params:xml:ns:caldav", "calendar-timezone" },
{ "urn:ietf:params:xml:ns:caldav", "supported-calendar-component-set" },
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
{ "urn:ietf:params:xml:ns:carddav", "addressbook-home-set" },
{ "urn:ietf:params:xml:ns:carddav", "addressbook-description" },
{ "urn:ietf:params:xml:ns:carddav", "supported-address-data" },
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
{ NULL, NULL }
};
m_davProps.clear();
m_session->propfindProp(path, 1, props, callback);
BOOST_FOREACH(Props_t::value_type &entry, m_davProps) {
const std::string &sub = entry.first;
const std::string &subType = entry.second["DAV::resourcetype"];
// new candidates are:
// - untested
// - not already a candidate
// - a resource
if (tried.find(sub) == tried.end() &&
candidates.find(sub) == candidates.end() &&
subType.find("<DAV:collection></DAV:collection>") != subType.npos) {
candidates.insert(sub);
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
if (next.empty() && typeMatches(entry.second)) {
// try this one before or all other candidates
next = sub;
}
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
SE_LOG_DEBUG(NULL, NULL, "new candidate: %s", sub.c_str());
}
}
}
}
if (next.empty()) {
// use next candidate
if (candidates.empty()) {
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
throwError(StringPrintf("no collection found in %s", m_settings->getURL().c_str()));
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
}
next = *candidates.begin();
candidates.erase(candidates.begin());
SE_LOG_DEBUG(NULL, NULL, "follow candidate %s", next.c_str());
}
counter++;
if (counter > limit) {
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
throwError(StringPrintf("giving up search for collection after %d attempts", limit));
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
}
path = next;
properly resolve relative ../events/ path for Google Added URI::resolve(), which is now used for Google default calendar if (and only if) starting with the "/user" or "/user/" URL.
2010-10-05 14:48:59 +02:00
}
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
// Pick final path.
m_calendar = m_session->getURI();
m_calendar.m_path = path;
SE_LOG_DEBUG(NULL, NULL, "picked final path %s", m_calendar.m_path.c_str());
WebDAVSource: debug dump of properties This verifies that reading properties works. For Google, the real calendar collection happens to be ../events/.
2010-10-05 13:17:06 +02:00
}
void WebDAVSource::openPropCallback(const Neon::URI &uri,
const ne_propname *prop,
const char *value,
const ne_status *status)
{
// TODO: recognize CALDAV:calendar-timezone and use it for local time conversion of events
WebDAV: find default calendar This patch implements a dynamic search for the "default" calendar of a user, starting with the user's principal URL: https://caldav.calendar.yahoo.com/dav/<user>/ https://www.google.com/calendar/dav/<user>/user/ Stops when: - current path is calendar collection (= contains VEVENTs) Gives up: - when running in circles - nothing else to try out - tried 10 times Follows: - CalDAV calendar-home-set - collections This implies that a specific calendar can be selected by using its URL directly. The search for "default" calendar is a bit random, because it depends on the naming of calendars on the server: calendars with lexicographically lower name are tested (and thus found) first.
2010-11-09 14:16:02 +01:00
std::string name;
if (prop->nspace) {
name = prop->nspace;
}
name += ":";
name += prop->name;
if (value) {
m_davProps[uri.m_path][name] = value;
boost::trim_if(m_davProps[uri.m_path][name],
boost::is_space());
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
bool WebDAVSource::isEmpty()
{
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
// listing all items is relatively efficient, let's use that
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// TODO: use truncated result search
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
RevisionMap_t revisions;
listAllItems(revisions);
return revisions.empty();
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
void WebDAVSource::close()
{
WebDAV: first version which can log into Google The Neon::Session wraps most of the relevant calls. It is parameterized by Neon::Settings. It is uncertain where all of these are meant to come from, because there is no peer configuration in many cases. Perhaps we can enforce that a WebDAV source may only be created in a context which has one and exactly one peer config? The current intermediate solution in WebDAVSourceRegister.cpp grabs all settings from WEBDAV_* env variables. Disabling SSL verification and Neon debug logging are implemented. Opening the source runs a few checks on the URL. Disabling SSL certificate checking turned out to be necessary, probably because of the known issue of gnutls not trusting the weak Google certificate chain.
2010-10-05 11:02:33 +02:00
m_session.reset();
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
WebDAVSource::Databases WebDAVSource::getDatabases()
{
Databases result;
// TODO: scan for right collections
result.push_back(Database("select database via relative URI",
"<path>"));
return result;
}
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
static const ne_propname getetag[] = {
{ "DAV:", "getetag" },
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
{ "DAV:", "resourcetype" },
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
{ NULL, NULL }
};
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
void WebDAVSource::listAllItems(RevisionMap_t &revisions)
{
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
bool failed = false;
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
m_session->propfindURI(m_calendar.m_path, 1, getetag,
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
boost::bind(&WebDAVSource::listAllItemsCallback,
this, _1, _2, boost::ref(revisions),
boost::ref(failed)));
if (failed) {
SE_THROW("incomplete listing of all items");
}
}
void WebDAVSource::listAllItemsCallback(const Neon::URI &uri,
const ne_prop_result_set *results,
RevisionMap_t &revisions,
bool &failed)
{
static const ne_propname prop = {
"DAV:", "getetag"
};
WebDAV: filter out collections inside collection Both CardDAV and CalDAV allow collections inside the collection of items which are to be synchronized. They may not contain other contact resp. calendar data and simply can be ignored. This patch is only relevant for CardDAV; CalDAV uses its own method for finding calendar items which already ignores non-calendar items.
2010-11-25 11:28:56 +01:00
static const ne_propname resourcetype = {
"DAV:", "resourcetype"
};
const char *type = ne_propset_value(results, &resourcetype);
if (type && strstr(type, "<DAV:collection></DAV:collection>")) {
// skip collections
return;
}
CalDAV: fixes for inserting items into Yahoo Content-Type must be set, otherwise Yahoo CalDAV rejects the items with "Bad Request". The resource name must match the UID + .ics. It is okay to escape special characters like @ in the PUT, even though the server doesn't do the same in PROPFIND. For change tracking we need a canonical form for DAV luids. Always unescaping the relative path component is safe. For absolute paths, we use the value as suggested by the server. There's no risk of mismatch here, because we never create such a luid ourself.
2010-11-09 17:16:43 +01:00
std::string uid = path2luid(uri.m_path);
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
if (uid.empty()) {
WebDAV: filter out collections inside collection Both CardDAV and CalDAV allow collections inside the collection of items which are to be synchronized. They may not contain other contact resp. calendar data and simply can be ignored. This patch is only relevant for CardDAV; CalDAV uses its own method for finding calendar items which already ignores non-calendar items.
2010-11-25 11:28:56 +01:00
// skip collection itself (should have been detected as collection already)
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
return;
}
WebDAV: filter out collections inside collection Both CardDAV and CalDAV allow collections inside the collection of items which are to be synchronized. They may not contain other contact resp. calendar data and simply can be ignored. This patch is only relevant for CardDAV; CalDAV uses its own method for finding calendar items which already ignores non-calendar items.
2010-11-25 11:28:56 +01:00
const char *etag = ne_propset_value(results, &prop);
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
if (etag) {
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
std::string rev = ETag2Rev(etag);
SE_LOG_DEBUG(NULL, NULL, "item %s = rev %s",
uid.c_str(), rev.c_str());
revisions[uid] = rev;
WebDAV: implemented item listing Listing items in WebDAV consists of getting the ETag for each URI directly underneath the collection. Checking for "empty source" is done by reading all pairs and then checking for non-empty map. It would be nice to abort the processing once an error is encountered or once "not empty" has been observed, but Neon does not support that. Probably for a good reason, because it would render the TCP connection useless.
2010-10-05 16:02:58 +02:00
} else {
failed = true;
SE_LOG_ERROR(NULL, NULL,
"%s: %s",
uri.toURL().c_str(),
Neon::Status2String(ne_propset_status(results, &prop)).c_str());
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
std::string WebDAVSource::path2luid(const std::string &path)
{
if (boost::starts_with(path, m_calendar.m_path)) {
CalDAV: fixes for inserting items into Yahoo Content-Type must be set, otherwise Yahoo CalDAV rejects the items with "Bad Request". The resource name must match the UID + .ics. It is okay to escape special characters like @ in the PUT, even though the server doesn't do the same in PROPFIND. For change tracking we need a canonical form for DAV luids. Always unescaping the relative path component is safe. For absolute paths, we use the value as suggested by the server. There's no risk of mismatch here, because we never create such a luid ourself.
2010-11-09 17:16:43 +01:00
return Neon::URI::unescape(path.substr(m_calendar.m_path.size()));
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
} else {
return path;
}
}
std::string WebDAVSource::luid2path(const std::string &luid)
{
CalDAV: fixes for inserting items into Yahoo Content-Type must be set, otherwise Yahoo CalDAV rejects the items with "Bad Request". The resource name must match the UID + .ics. It is okay to escape special characters like @ in the PUT, even though the server doesn't do the same in PROPFIND. For change tracking we need a canonical form for DAV luids. Always unescaping the relative path component is safe. For absolute paths, we use the value as suggested by the server. There's no risk of mismatch here, because we never create such a luid ourself.
2010-11-09 17:16:43 +01:00
if (boost::starts_with(luid, "/")) {
return luid;
} else {
return m_calendar.resolve(Neon::URI::escape(luid)).m_path;
}
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
void WebDAVSource::readItem(const string &uid, std::string &item, bool raw)
{
WebDAV: some testing and fixes for iCalendar 2.0 with Google The tests must run with a modified ical20.ics.google.tem which does not contain RECURRENCE-ID, because that is not yet supported. Also, our complex 1234567890!@#$%^&*()<>@dummy must be avoided because Google has an issue with it (doesn't find resulting resource): CLIENT_TEST_SERVER=google CLIENT_TEST_SIMPLE_UID=1 ./client-test Client::Source::caldav_ical20::testImport This patch fixes some (but not all) issues found in testImport: - readItem() did not clear the item string before appending the new item. - Detection of "item existed already" cannot use the alternative name returned by the server, because Google does that also for items which are really new. - The test registered itself as "ical20", which conflicts with the EDS backend. Now use "caldav_ical20".
2010-10-08 15:13:58 +02:00
item.clear();
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
Neon::Request req(*m_session, "GET", luid2path(uid),
"", item);
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// useful with CardDAV: server might support more than vCard 3.0, but we don't
req.addHeader("Accept", contentType());
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
req.run();
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
TrackingSyncSource::InsertItemResult WebDAVSource::insertItem(const string &uid, const std::string &item, bool raw)
{
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
std::string new_uid;
std::string rev;
bool update = false; /* true if adding item was turned into update */
std::string result;
if (uid.empty()) {
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
// Pick a resource name (done by derived classes, by default random),
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
// catch unexpected conflicts via If-None-Match: *.
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
std::string buffer;
const std::string *data = createResourceName(item, buffer, new_uid);
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
Neon::Request req(*m_session, "PUT", luid2path(new_uid),
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
*data, result);
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
req.setFlag(NE_REQFLAG_IDEMPOTENT, 0);
req.addHeader("If-None-Match", "*");
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
req.addHeader("Content-Type", contentType().c_str());
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
req.run();
SE_LOG_DEBUG(NULL, NULL, "add item status: %s",
Neon::Status2String(req.getStatus()).c_str());
switch (req.getStatusCode()) {
case 204:
// stored, potentially in a different resource than requested
// when the UID was recognized
break;
case 201:
// created
break;
default:
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
SE_THROW_EXCEPTION_STATUS(TransportStatusException,
std::string("unexpected status for insert: ") +
Neon::Status2String(req.getStatus()),
SyncMLStatus(req.getStatus()->code));
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
break;
}
rev = getETag(req);
std::string real_luid = getLUID(req);
if (!real_luid.empty()) {
WebDAV: some testing and fixes for iCalendar 2.0 with Google The tests must run with a modified ical20.ics.google.tem which does not contain RECURRENCE-ID, because that is not yet supported. Also, our complex 1234567890!@#$%^&*()<>@dummy must be avoided because Google has an issue with it (doesn't find resulting resource): CLIENT_TEST_SERVER=google CLIENT_TEST_SIMPLE_UID=1 ./client-test Client::Source::caldav_ical20::testImport This patch fixes some (but not all) issues found in testImport: - readItem() did not clear the item string before appending the new item. - Detection of "item existed already" cannot use the alternative name returned by the server, because Google does that also for items which are really new. - The test registered itself as "ical20", which conflicts with the EDS backend. Now use "caldav_ical20".
2010-10-08 15:13:58 +02:00
// Google renames the resource automatically to something of the form
// <UID>.ics. Interestingly enough, our 1234567890!@#$%^&*()<>@dummy UID
// test case leads to a resource path which Google then cannot find
// via CalDAV. client-test must run with CLIENT_TEST_SIMPLE_UID=1...
SE_LOG_DEBUG(NULL, NULL, "new item mapped to %s", real_luid.c_str());
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
new_uid = real_luid;
WebDAV: some testing and fixes for iCalendar 2.0 with Google The tests must run with a modified ical20.ics.google.tem which does not contain RECURRENCE-ID, because that is not yet supported. Also, our complex 1234567890!@#$%^&*()<>@dummy must be avoided because Google has an issue with it (doesn't find resulting resource): CLIENT_TEST_SERVER=google CLIENT_TEST_SIMPLE_UID=1 ./client-test Client::Source::caldav_ical20::testImport This patch fixes some (but not all) issues found in testImport: - readItem() did not clear the item string before appending the new item. - Detection of "item existed already" cannot use the alternative name returned by the server, because Google does that also for items which are really new. - The test registered itself as "ical20", which conflicts with the EDS backend. Now use "caldav_ical20".
2010-10-08 15:13:58 +02:00
// TODO: find a better way of detecting unexpected updates.
// update = true;
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
} else if (!rev.empty()) {
// Yahoo Contacts returns an etag, but no href. For items
// that were really created as requested, that's okay. But
// Yahoo Contacts silently merges the new contact with an
// existing one, presumably if it is "similar" enough. The
// web interface allows creating identical contacts
// multiple times; not so CardDAV. We are not even told
// the path of that other contact... Detect this by
// checking whether the item really exists.
RevisionMap_t revisions;
bool failed = false;
m_session->propfindURI(luid2path(new_uid), 0, getetag,
boost::bind(&WebDAVSource::listAllItemsCallback,
this, _1, _2, boost::ref(revisions),
boost::ref(failed)));
// Turns out we get a result for our original path even in
// the case of a merge, although the original path is not
// listed when looking at the collection. Let's use that
// to return the "real" uid to our caller.
if (revisions.size() == 1 &&
revisions.begin()->first != new_uid) {
SE_LOG_DEBUG(NULL, NULL, "%s mapped to %s by peer",
new_uid.c_str(),
revisions.begin()->first.c_str());
new_uid = revisions.begin()->first;
update = true;
}
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
}
} else {
new_uid = uid;
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
std::string buffer;
const std::string *data = setResourceName(item, buffer, new_uid);
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
Neon::Request req(*m_session, "PUT", luid2path(new_uid),
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
*data, result);
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
req.setFlag(NE_REQFLAG_IDEMPOTENT, 0);
WebDAV: added CardDAV support This patch moves some of the CalDAV-specific code out of WebDAVSource into CalDAVSource and adds the corresponding CardDAV code in the new CardDAVSource. It improves searching for the right collection. A Yahoo Contacts specific problem is that vCard UID and resource name have to match, with ".vcf" used as suffix in the resource name. The new createResourceName() and setResourceName() virtual methods ensure that. They are nops in CalDAV and use simple string manipulation for vCard. Another Yahoo Contacts odity is merging of contacts in PUT, without telling the client. This can be detected by checking the expected resource name with PROPFIND: the server then replies with the real resource name. This check is done only if no href is returned in the response to PUT, so it should only be triggered for Yahoo Contacts. CardDAV support is still experimental. It was tested with Yahoo Contacts, using https://carddav.address.yahoo.com/dav/%u as sync URL. This is different from the CalDAV URL, which currently prevents using the same @yahoo context for both calendar and contacts. Working on CardDAV showed that resource name comparisons had issues due to different encoding of special characters. Added canonicalization of paths to fix this problem. This also includes appending the trailing slash for collections (Neon::URI::normalizePath()). Note that Buteo only serializes sync sessions based on their type, so as soon as we allow CardDAV in addition to CalDAV, it might happen that SyncEvolution is invokved multiple times in parallel => need to remove global variables first.
2010-11-25 10:08:07 +01:00
req.addHeader("Content-Type", contentType());
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
// TODO: match exactly the expected revision, aka ETag,
// or implement locking. Note that the ETag might not be
// known, for example in this case:
// - PUT succeeds
// - PROPGET does not
// - insertItem() fails
// - Is retried? Might need slow sync in this case!
//
// req.addHeader("If-Match", etag);
req.run();
SE_LOG_DEBUG(NULL, NULL, "update item status: %s",
Neon::Status2String(req.getStatus()).c_str());
switch (req.getStatusCode()) {
case 204:
// the expected outcome, as we were asking for an overwrite
break;
case 201:
WebDAVSource: 201 okay for update Strictly speaking, 201 is for item creation. But Google sometimes also sends it during an update, so accept it.
2010-11-04 15:59:52 +01:00
// Huh? Shouldn't happen, but Google sometimes reports it
// even when updating an item. Accept it.
// SE_THROW("unexpected creation instead of update");
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
break;
default:
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
SE_THROW_EXCEPTION_STATUS(TransportStatusException,
std::string("unexpected status for update: ") +
Neon::Status2String(req.getStatus()),
SyncMLStatus(req.getStatus()->code));
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
break;
}
rev = getETag(req);
std::string real_luid = getLUID(req);
if (!real_luid.empty() && real_luid != new_uid) {
SE_THROW(StringPrintf("updating item: real luid %s does not match old luid %s",
real_luid.c_str(), new_uid.c_str()));
}
}
if (rev.empty()) {
// Server did not include etag header. Must request it
// explicitly (leads to race condition!). Google Calendar
// assigns a new ETag even if the body has not changed,
// so any kind of caching of ETag would not work either.
bool failed = false;
RevisionMap_t revisions;
m_session->propfindURI(luid2path(new_uid), 0, getetag,
boost::bind(&WebDAVSource::listAllItemsCallback,
this, _1, _2, boost::ref(revisions),
boost::ref(failed)));
rev = revisions[new_uid];
if (failed || rev.empty()) {
SE_THROW("could not retrieve ETag");
}
}
return InsertItemResult(new_uid, rev, update);
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
WebDAV: implemented insertion of items This works for updating and adding an item. Storing a new item under a different resouce URI is also handled, which can happen with CalDAV when there is already an item with the same UID. It would be nice if the server returned a ETag in response to a PUT, but Google Calendar doesn't do that. The header is checked neverthless (untested!), with an explicit PROPGET as fallback. This patch also clarifies LUID (relative if possible, absolute if not) and revision string handling (without W/ and quotation marks). We don't care about weak ETags at the moment, Google doesn't use them. Even if a server did, what would we do with the information that the item wasn't stored verbatim? The current implementation is not yet good enough for CalDAV: - only one VEVENT per UID supported: must merge and split related VEVENTs into one CalDAV calendar resource - adding or updating VEVENT without UID probably fails: must insert new or old UID
2010-10-06 11:21:11 +02:00
std::string WebDAVSource::ETag2Rev(const std::string &etag)
{
std::string res = etag;
if (boost::starts_with(res, "W/")) {
res.erase(0, 2);
}
if (res.size() >= 2) {
res = res.substr(1, res.size() - 2);
}
return res;
}
std::string WebDAVSource::getLUID(Neon::Request &req)
{
std::string location = req.getResponseHeader("Location");
if (location.empty()) {
return location;
} else {
return path2luid(Neon::URI::parse(location).m_path);
}
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
void WebDAVSource::removeItem(const string &uid)
{
WebDAV: implemented removeItem() Mapping removeItem() to DELETE is straight-forward. Except that CalDAV will require additional support for removing individual VEVENTs from a resource that contains more than one VEVENT...
2010-10-06 11:43:39 +02:00
std::string item, result;
Neon::Request req(*m_session, "DELETE", luid2path(uid),
item, result);
// TODO: match exactly the expected revision, aka ETag,
// or implement locking.
// req.addHeader("If-Match", etag);
req.run();
SE_LOG_DEBUG(NULL, NULL, "remove item status: %s",
Neon::Status2String(req.getStatus()).c_str());
switch (req.getStatusCode()) {
case 204:
// the expected outcome
break;
default:
WebDAV error codes: map to SyncMLStatus This patch enhances error handling so that a more specific TransportStatusException with the right SyncMLStatus inside is thrown. This is necessary to report back authentication errors.
2010-10-29 17:25:20 +02:00
SE_THROW_EXCEPTION_STATUS(TransportStatusException,
std::string("unexpected status for removal: ") +
Neon::Status2String(req.getStatus()),
SyncMLStatus(req.getStatus()->code));
WebDAV: implemented removeItem() Mapping removeItem() to DELETE is straight-forward. Except that CalDAV will require additional support for removing individual VEVENTs from a resource that contains more than one VEVENT...
2010-10-06 11:43:39 +02:00
break;
}
WebDAV: initial commit of skeleton sources and build scripts
2010-10-04 15:06:18 +02:00
}
SE_END_CXX
#endif /* ENABLE_DAV */
#ifdef ENABLE_MODULES
# include "WebDAVSourceRegister.cpp"
#endif