Problem updating calendar items (SOGo), possibly HTTP header-problem

  • Hello,

    this is my first post here after successfully using DAVx5 (since early versions of DavDroid) and a self hosted SOGo server.

    I currently have the following environment:


    • DAVx5 4.0.0, Android 8 (this has the update problem)
    • Evolution 3.40.4 (no problems)

    Server: SOGo 5.2.0 with nginx reverse proxy on Arch-Linux, identical behavior on two different servers

    How to reproduce:

    • Create event
    • Sync, verify in SOGo webinterface
    • Modify event
    • Sync, modification is reverted on Android and does never show in webinterface

    I have captured the PUT requests for the changes and the If-Match header seems fishy to me.

    • PUT for create returns status 201 with:
    ETag: "gcs00000000"\r\n
    • PUT for update returns status 412 and has:
    if-match: "\"gcs00000000\""\r\n

    It seems to me the additional " prevent correct matching of the etag.
    Suppressing the if-match-header in nginx works around the (these) lost updates, but that can’t be a correct solution.

    Has somebody seen similar problems?

  • developer

    This post is deleted!
  • developer


    I have tested with our SOGo test server and couldn’t reproduce the problem.

    I have captured the PUT requests for the changes and the If-Match header seems fishy to me.

    • PUT for create returns status 201 with:
    ETag: "gcs00000000"\r\n

    Correct, I see the same. DAVx5 parses it correctly here:

    2021-10-18 16:24:22.385 3247-7264/at.bitfire.davdroid V/davx5: [HttpClient] ETag: “gcs00000001”
    2021-10-18 16:24:22.385 3247-7264/at.bitfire.davdroid V/davx5: [HttpClient] <-- END HTTP (0-byte body)
    2021-10-18 16:24:22.385 3247-7264/at.bitfire.davdroid D/davx5: [syncadapter.SyncManager] Received new ETag=gcs00000001 after uploading [without ", as expected]

    And then DAVx5 sends it as expected:

    2021-10-18 16:24:19.411 3247-7264/at.bitfire.davdroid V/davx5: [HttpClient] If-Match: “gcs00000000”

    And everything works…

    Can you maybe provide a test account so that we can have a look?

  • @rfc2822 Hi, thanks for checking.
    I will send you credentials for a test account via chat.

    It seems the additional " come from DAVx5. I have used adb to get logs from the phone:

    10-18 16:47:01.470 24865 28198 V davx5   : [HttpClient] etag: "gcs00000000"

    but updating yields:

    10-18 16:47:15.248 24865 28228 V davx5   : [HttpClient] If-Match: "\"gcs00000000\""
  • developer

    @halemmerich As you have already pointed out over PM, it may be related to this problem:

    Is this already known at SOGo / are there server-side fixes or workarounds? There shouldn’t be a BOM in front of every string.

  • I have created a better workaround than killing the If-Match header using nginx’s java script module:

    load_module /usr/lib/nginx/modules/;
      js_import filter from /etc/nginx/filter.js;
      server  {
        location ^~/SOGo {
          js_body_filter filter.filterBody;
          js_header_filter filter.filterHeader;
          proxy_set_header Accept-Encoding "identity";


    var body = new Array();
    var newBodyLength = null;
    function filterBody(r, data, flags){
            if (flags.last){
                    data = body.join('');
                    data = data.replace(/&#65279;/g, '');
                    newBodyLength = data.length;
                    r.sendBuffer(data, flags);
    function filterHeader(r){
            r.headersOut['Content-Length'] = newBodyLength;
    export default {filterBody, filterHeader};

    Rest of the config is pretty much what you can find in the SOGo wiki.

    The performance is probably horrible and I don’t know anything about potential security implications of this solution, but it seems to work. YMMV.

    This was inspired by this post:

  • @rfc2822

    My mail to the users mailing list was ignored, but somebody else created a bug ticket with debugging info leading to a gnustep-base upgrade as the cause:

Similar topics