View Issue Details

IDProjectCategoryView StatusLast Update
0002311SOGo Connectorwith external serverpublic2014-02-07 13:38
ReporterMichelR Assigned Toludovic  
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionfixed 
Fixed in Version24.0.4 
Summary0002311: Sogo doesn't handle a 403 response after a REPORT request
Description

The problem appeared with IceWarp server and Connector v17.0.5. Here is the process :

-1- Sogo makes a PROPFIND request
-2- icewarp answers with a list of possible requests (specially
"sync-collection")
-3- if "sync-collection" is supported, then sogo makes a REPORT request with a sync-token (sent by icewarp in a previous synchro and stored in sogo)
-4- icewarp answers : default behavior is an empty answer with 403 error code
-5- 2 problems :

  • Sogo does nothing, while the RFC says that Sogo should send another request to perform a full sync
  • Sogo keeps the request in an instable state : the request is not closed and no other sync request can be performed
Additional Information

I'm a dev and currently working on this bug.
where should I send patches ? Who should I contact for a code review ?
Cheers

TagsNo tags attached.

Activities

onofabio

onofabio

2013-05-10 09:56

reporter   ~0005573

I have similar problem with PHP-Push-2 project.
When I try contact sync, the server response is 403 on REPORT query.

I've changed query in PROPFIND and sync seems work correctly.... but I think this is not a solution.

Christian Mack

Christian Mack

2013-05-10 14:35

developer   ~0005575

@MichelR
Add patches to this bug report

ludovic

ludovic

2013-05-24 11:40

administrator   ~0005609

Any updates on the patches?

2013-05-28 08:33

 

icewarp_403.patch (1,199 bytes)   
diff --git a/chrome/content/sogo-connector/general/sync.addressbook.groupdav.js b/chrome/content/sogo-connector/general/sync.addressbook.groupdav.js
index 848c38b..6de7c67 100644
--- a/chrome/content/sogo-connector/general/sync.addressbook.groupdav.js
+++ b/chrome/content/sogo-connector/general/sync.addressbook.groupdav.js
@@ -1215,7 +1215,20 @@ new:
             }
         }
         else
-            dump("onServerHashQueryComlete: the server returned an empty response\n");
+        {
+            dump("onServerSyncQueryComplete: the server returned an empty response\n");
+            // We handle a special case : server returns a 403 status but with an empty response.
+            // It is not well defined in RFC how to handle that.
+            // It seems that IceWarp Server wants the client to retry without a token.
+            if (status == 403) {
+                dump("[sogo-connector] received '403' status"
+                     + ", retrying without a token...\n");
+                this.webdavSyncToken = "";
+                this.triggerWebDAVSync();
+            } else {
+                this.abort();
+            }
+        }
     },
 
     processCards: function() {
icewarp_403.patch (1,199 bytes)   
MichelR

MichelR

2013-05-28 08:39

reporter   ~0005616

Please find the file "icewarp_403.patch"
I don't know if the added line "this.abort()" is correct, or if "abort()" needs to be modified to handle this new case.

In a similar way, I have a question about the "onServerHashQueryComplete" method (/chrome/content/sogo-connector/general/sync.addressbook.groupdav.js) :

current version :

onServerHashQueryComplete: function(status, jsonResponse) {

    ...
    if (jsonResponse) {
        if (status > 199 && status < 400) {
            ...
        }
        else
            this.abort();
    }
    else
        dump("onServerHashQueryComlete: the server returned an empty response\n");
},

Shouldn't it need a "abort()" when there is no json response ?

onServerHashQueryComplete: function(status, jsonResponse) {

    ...
    if (jsonResponse) {
        if (status > 199 && status < 400) {
            ...
        }
        else
            this.abort();
    }
    else
    {
        dump("onServerHashQueryComlete: the server returned an empty response\n");
        this.abort();
    }
},

ludovic

ludovic

2014-02-07 13:38

administrator   ~0006520

Patch pushed: https://github.com/inverse-inc/sogo-connector.tb24/commit/e90acfbe7de32992e61108a446fd34eed9978765

I don't understand your command 0005616 - that's exactly what the patch does!

Issue History

Date Modified Username Field Change
2013-05-09 16:14 MichelR New Issue
2013-05-10 09:56 onofabio Note Added: 0005573
2013-05-10 14:35 Christian Mack Note Added: 0005575
2013-05-24 11:40 ludovic Note Added: 0005609
2013-05-28 08:33 MichelR File Added: icewarp_403.patch
2013-05-28 08:39 MichelR Note Added: 0005616
2013-09-17 19:37 jraby Status new => assigned
2013-09-17 19:37 jraby Assigned To => jraby
2014-02-07 13:38 ludovic Note Added: 0006520
2014-02-07 13:38 ludovic Status assigned => closed
2014-02-07 13:38 ludovic Assigned To jraby => ludovic
2014-02-07 13:38 ludovic Resolution open => fixed
2014-02-07 13:38 ludovic Fixed in Version => 24.0.4