Tickets :: [#7769] Linux Funambol 0.7+ on thunderbird gives send http request error

6.0.0-alpha14

6/24/25

Summary	Linux Funambol 0.7+ on thunderbird gives send http request error
Queue	Synchronization
Type	Bug
State	Resolved
Priority	2. Medium
Owners	jan (at) horde (dot) org
Requester	highvoltspam (at) gmail (dot) com
Created	12/11/2008 (6039 days ago)
Due
Updated	01/13/2010 (5641 days ago)
Assigned	07/10/2009 (5828 days ago)
Resolved	08/12/2009 (5795 days ago)
Github Issue Link
Github Pull Request
Milestone	3.3.5
Patch	No

01/13/2010 12:10:22 AM	CVS Commit	Comment #19	Reply to this comment
Changes have been made in Git for this ticket: MFB: Start output compression conditionally (~~Bug #7769~~). http://git.horde.org/diff.php/chora/lib/base.php?rt=horde-git&r1=f91c0d058e250c0e421c0f82a0263497ceefdab0&r2=cc5e798aa47467477d1574428bbf77030d221562 http://git.horde.org/diff.php/ingo/lib/base.php?rt=horde-git&r1=f91c0d058e250c0e421c0f82a0263497ceefdab0&r2=cc5e798aa47467477d1574428bbf77030d221562 http://git.horde.org/diff.php/kronolith/lib/base.php?rt=horde-git&r1=f91c0d058e250c0e421c0f82a0263497ceefdab0&r2=cc5e798aa47467477d1574428bbf77030d221562 http://git.horde.org/diff.php/nag/lib/base.php?rt=horde-git&r1=f91c0d058e250c0e421c0f82a0263497ceefdab0&r2=cc5e798aa47467477d1574428bbf77030d221562 http://git.horde.org/diff.php/turba/lib/base.php?rt=horde-git&r1=f91c0d058e250c0e421c0f82a0263497ceefdab0&r2=cc5e798aa47467477d1574428bbf77030d221562

08/12/2009 10:33:45 PM	Jan Schneider	Comment #18 State ⇒ Resolved	Reply to this comment
Fixed in CVS.

08/12/2009 10:32:53 PM	CVS Commit	Comment #17	Reply to this comment
Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/kronolith/docs/CHANGES?rt=horde&r1=1.165.2.264&r2=1.165.2.265&ty=u http://cvs.horde.org/diff.php/mnemo/docs/CHANGES?rt=horde&r1=1.63.2.78&r2=1.63.2.79&ty=u http://cvs.horde.org/diff.php/nag/docs/CHANGES?rt=horde&r1=1.115.2.116&r2=1.115.2.117&ty=u http://cvs.horde.org/diff.php/turba/docs/CHANGES?rt=horde&r1=1.181.2.229&r2=1.181.2.230&ty=u

08/12/2009 10:28:15 PM	CVS Commit	Comment #16	Reply to this comment
Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/chora/lib/base.php?rt=horde&r1=1.101.10.2&r2=1.101.10.3&ty=u http://cvs.horde.org/diff.php/hermes/lib/base.php?rt=horde&r1=1.36&r2=1.36.2.1&ty=u http://cvs.horde.org/diff.php/ingo/lib/base.php?rt=horde&r1=1.56.10.3&r2=1.56.10.4&ty=u http://cvs.horde.org/diff.php/klutz/backend.php?rt=horde&r1=1.75.2.1&r2=1.75.2.2&ty=u http://cvs.horde.org/diff.php/klutz/lib/base.php?rt=horde&r1=1.44&r2=1.44.2.1&ty=u http://cvs.horde.org/diff.php/kronolith/lib/base.php?rt=horde&r1=1.117.8.16&r2=1.117.8.17&ty=u http://cvs.horde.org/diff.php/mnemo/lib/base.php?rt=horde&r1=1.46.10.13&r2=1.46.10.14&ty=u http://cvs.horde.org/diff.php/nag/lib/base.php?rt=horde&r1=1.75.10.7&r2=1.75.10.8&ty=u http://cvs.horde.org/diff.php/turba/lib/base.php?rt=horde&r1=1.62.10.21&r2=1.62.10.22&ty=u http://cvs.horde.org/diff.php/whups/lib/base.php?rt=horde&r1=1.75.2.1&r2=1.75.2.2&ty=u

07/11/2009 05:58:51 PM	Jan Schneider	Milestone ⇒ 3.3.5

07/10/2009 03:01:08 AM	Chuck Hagenbuch	Comment #15 State ⇒ Assigned	Reply to this comment
Looks like we have a culprit then. Back to Jan...

07/10/2009 02:32:29 AM	devendralaulkar (at) yahoo (dot) com	Comment #14 New Attachment: horde_debug_2.log	Reply to this comment
My current theory is that when an application method is used, that app's base.php is loaded, and that's where compressOutput gets called despite the no_compress global. Yes, in Turba's base.php we have on line 119 // Start compression, if requested. Horde::compressOutput(); which is getting called. Attaching portion of the stack trace in horde_debug_2.log

07/10/2009 01:26:22 AM	Chuck Hagenbuch	Comment #13	Reply to this comment
debug_backtrace() will get you a (warning - large) stack trace. If you put that in the beginning of Horde::compressOutput and just dump the first one or two elements of the resulting array, you can find out where compressOutput was called from. My current theory is that when an application method is used, that app's base.php is loaded, and that's where compressOutput gets called despite the no_compress global.

07/10/2009 01:03:27 AM	devendralaulkar (at) yahoo (dot) com	Comment #12	Reply to this comment
Where is Horde::compressOutput being called? In FW3 (latest stable), horde/lib/base.php doesn't call Horde::compressOutput() if $no_compress is set. In attached horde.log I see :- Jul 08 17:03:31 HORDE [info] [turba] gzip enabled [pid 7142 on line 1252 of "/home/shell_home/a_website/horde/lib/Horde.php"] Is there a way to get stack trace ? I can put in some additional debugs and find out. Sorry but I have only basic knowledge of PHP (and also Horde)

07/10/2009 12:10:29 AM	Chuck Hagenbuch	Comment #11 State ⇒ Feedback	Reply to this comment
After some testing, I figured out the problem. In Horde.php in function compressOutput() - We are not checking for $no_compress set in rpc.php. Hence, the function enables compression using the global setting. Where is Horde::compressOutput being called? In FW3 (latest stable), horde/lib/base.php doesn't call Horde::compressOutput() if $no_compress is set.

07/09/2009 12:59:41 AM	devendralaulkar (at) yahoo (dot) com	Comment #10	Reply to this comment
After some testing, I figured out the problem. In Horde.php in function compressOutput() - We are not checking for $no_compress set in rpc.php. Hence, the function enables compression using the global setting. This can be easily resolved by checking if $no_compress is true. Patch for Horde.php is as follows 1235a1236,1239 if($GLOBALS['no_compress']) { return; } This compresses the pages properly when enabled, and disables compression when called from rpc.php (as I have tested) Cheers, Devendra Laulkar.

07/09/2009 12:11:56 AM	devendralaulkar (at) yahoo (dot) com	Comment #9 New Attachment: horde.log	Reply to this comment
Bug reproduced. Horde version v3.3.4 PHP Version 5.2.9 I can reproduce the bug. When gzip compression is enable, the sync fails in Thunderbird. When the compression is disable, the sync works fine. Looks like the gzip compression is not disable. Attaching logs as requested.

04/20/2009 08:37:45 AM	Jan Schneider	State ⇒ No Feedback

04/05/2009 08:46:13 PM	Jan Schneider	Comment #8 State ⇒ Feedback	Reply to this comment
In horde/rpc.php we explicitly disable page compression for SyncML request (lines 40 and 45). Since the gzip headers are sent by PHP, not Horde, and only if compression is turned on, I have no idea how they could be sent out if we don't use page compression. To verify that this works correctly, please add some debug code to Horde::compressOutput() in lib/Horde.php, e.g. Horde::logMessage('gzip enabled', __FILE__, __LINE__); after the ob_start() line.

03/30/2009 12:51:47 PM	Jan Schneider	Assigned to Jan Schneider State ⇒ Assigned Priority ⇒ 2. Medium

03/27/2009 09:25:30 AM	silbermondauge (at) fantasymail (dot) de	Comment #7	Reply to this comment
Are you saying that this is what Horde does, i.e. sending a Content-Encoding: gzip header but plain, uncompressed data? Did you confirm that with a network sniffer? Which Horde version do you use, and does page compression work on regular pages? I ran a tcp-dump and saw a Content-Encoding: gzip header and uncompressed content. Then I tried to disable compression in Horde config and synchronization worked. Unfortunately I cannot reproduce the problem at the moment - I probably would have to reset sync state. It seems like it happens only under special circumstances. Maybe the windows client can accept the compression mismatch or it does not occur at all. My current horde version is 3.3.3, my php version is 5.2.6 and gzip compression is disabled in php. Compression was enabled in horde at the beginnung. I can try to reproduce the problem but I am working about 10 hours a day at the moment so I probably do not have enough time soon.

03/26/2009 12:22:40 AM	highvoltspam (at) gmail (dot) com	Comment #6	Reply to this comment
I can also confirm that turning off the php gzip option in the horde settings solves the problem. This bug seems to be caused by sending an uncompressed response while sending a gzip-Compressed HTTP response header. Turning of compression in the horde settings fixes the problem. I have turned of gzip compression in php.ini

03/25/2009 04:48:28 PM	Jan Schneider	Comment #5 State ⇒ Feedback	Reply to this comment
Are you saying that this is what Horde does, i.e. sending a Content-Encoding: gzip header but plain, uncompressed data? Did you confirm that with a network sniffer? Which Horde version do you use, and does page compression work on regular pages?

03/25/2009 04:29:05 PM	silbermondauge (at) fantasymail (dot) de	Comment #4	Reply to this comment
This bug seems to be caused by sending an uncompressed response while sending a gzip-Compressed HTTP response header. Turning of compression in the horde settings fixes the problem. I have turned of gzip compression in php.ini

12/11/2008 03:48:03 PM	Jan Schneider	Comment #3 Priority ⇒ 1. Low State ⇒ Not A Bug	Reply to this comment
Sounds like a Funambol bug then.

12/11/2008 03:30:57 PM	highvoltspam (at) gmail (dot) com	Comment #2	Reply to this comment
[Show Quoted Text - 16 lines][Hide Quoted Text] I have Horde Groupware Webmail Edition 1.2 it's working together with an IMAP server and MySQL DB. I use Thunderbird 2.0.0.18 and i tried all the funambol plugins for it (linux versions). I think I tried every setting there is in horde, but I always get this error in funambol 0.7 : "error sending http request". (in the experimental funambol 0.8, the error is something like cannot connect to server) I tried with a previous version of horde (a version of about 9 months old), and there it seems to work. So I think I can be sure that this is not the fault of funambol.. php.log doesnt give any specific error either. Any suggestions please ? I have an update to this. Connecting with funambol 0.8 on a windows platform works... So, is this a horde or funambol bug? maybe it's both. (I crossposted this issue also on the funambol maillinglist)

12/11/2008 01:17:44 AM	highvoltspam (at) gmail (dot) com	Comment #1 Priority ⇒ 3. High State ⇒ Unconfirmed New Attachment: syncmllog.tar.gz Patch ⇒ No Milestone ⇒ Queue ⇒ Synchronization Summary ⇒ Linux Funambol 0.7+ on thunderbird gives send http request error Type ⇒ Bug	Reply to this comment
I have Horde Groupware Webmail Edition 1.2 it's working together with an IMAP server and MySQL DB. I use Thunderbird 2.0.0.18 and i tried all the funambol plugins for it (linux versions). I think I tried every setting there is in horde, but I always get this error in funambol 0.7 : "error sending http request". (in the experimental funambol 0.8, the error is something like cannot connect to server) I tried with a previous version of horde (a version of about 9 months old), and there it seems to work. So I think I can be sure that this is not the fault of funambol.. php.log doesnt give any specific error either. Any suggestions please ?