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:

    Clients:

    • 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

    Debugging:
    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

    Hi,

    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:

    https://forums.bitfire.at/post/14400

    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/ngx_http_js_module.so;
    
    http{
      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";
          ...
      }
    }
    
    

    filter.js:

    var body = new Array();
    var newBodyLength = null;
    
    function filterBody(r, data, flags){
            body.push(data);
            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: https://forums.bitfire.at/post/14422


  • @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:

    https://www.sogo.nu/bugs/view.php?id=5416
    https://github.com/gnustep/libs-base/issues/212

Similar topics