[SyncEvolution] utf-8 not supported-error using syncevo-http-server

[Patrick Ohly]

On Wed, 2014-01-08 at 11:34 +0100, Thorsten Leiser wrote:
> Hi,
>  
> I'm using syncevolution-bundle 1.3.2-2 for syncing my nokia 515 dual
> sim (S40 / V 09.04) with my OwnCloud 5-Server.
> Currently it's a bluetooth sync one-way from my ubuntu 12.04 laptop to
> the phone.
> The sync goes like this:
> Server via Cal-/CardDAV ==> local SyncEvo-DB via Bluetooth/OBEX ==>
> Nokia 515
> The construct is runnig stable, so far so good.
> Now I'm trying to use the syncevo-http-server to make a direct sync
> between a ubuntu 12.04 server with my nokia phone.
> I start the server with "syncevo-http-server
> http://localhost:9000/syncml".
> Now, if the phone tries to connect to the server, the sync stops and i
> got the following error on the console:
>  
> [INFO] syncevo-http: new SyncML session for 2.205.150.113
> [INFO] syncevo-dbus-server: /org/syncevolution/Server: ready to run
> [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type
> 'application/vnd.syncml+wbxml; charset=UTF-8' not supported for
> starting a sync
>  
> I tried the same procedure with the latest unstable version of the
> syncevo-bundle, same error. Has anyone an idea?

There is code to handle the extra "; charset=UTF-8", but only for XML
messages (where it makes sense), and not for wbxml (where it probably is
useless):


src/dbus/server/connection.cpp:

            } else if (// relaxed checking for XML: ignore stuff like "; CHARSET=UTF-8"
                       message_type.substr(0, message_type.find(';')) == TransportAgent::m_contentTypeSyncML ||
                       message_type == TransportAgent::m_contentTypeSyncWBXML) {


Change the second comparison to
             message_type.substr(0, message_type.find(';')) == TransportAgent::m_contentTypeSyncWBXML
and it should work.

Can you recompile SyncEvolution? Otherwise you'll have to wait for 1.3.99.7.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.