Fri, 10 Apr 2026 06:14:17 +0000 https://bugs.horde.org/ticket/7769 Linux Funambol 0.7+ on thunderbird gives send http request error 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 ? Thu, 11 Dec 2008 01:17:44 +0000 https://bugs.horde.org/ticket/7769#t51188 > 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) Thu, 11 Dec 2008 15:30:57 +0000 https://bugs.horde.org/ticket/7769#t51196 Sounds like a Funambol bug then. Thu, 11 Dec 2008 15:48:03 +0000 https://bugs.horde.org/ticket/7769#t51198 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 Wed, 25 Mar 2009 16:29:05 +0000 https://bugs.horde.org/ticket/7769#t53280 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? Wed, 25 Mar 2009 16:48:28 +0000 https://bugs.horde.org/ticket/7769#t53283 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 Thu, 26 Mar 2009 00:22:40 +0000 https://bugs.horde.org/ticket/7769#t53305 > 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. Fri, 27 Mar 2009 09:25:30 +0000 https://bugs.horde.org/ticket/7769#t53334 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. Sun, 05 Apr 2009 20:46:13 +0000 https://bugs.horde.org/ticket/7769#t53523 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. Thu, 09 Jul 2009 00:11:56 +0000 https://bugs.horde.org/ticket/7769#t54850 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. Thu, 09 Jul 2009 00:59:41 +0000 https://bugs.horde.org/ticket/7769#t54851 > 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. Fri, 10 Jul 2009 00:10:29 +0000 https://bugs.horde.org/ticket/7769#t54871 > 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) Fri, 10 Jul 2009 01:03:27 +0000 https://bugs.horde.org/ticket/7769#t54876 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. Fri, 10 Jul 2009 01:26:22 +0000 https://bugs.horde.org/ticket/7769#t54877 > 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 Fri, 10 Jul 2009 02:32:29 +0000 https://bugs.horde.org/ticket/7769#t54882 Looks like we have a culprit then. Back to Jan... Fri, 10 Jul 2009 03:01:08 +0000 https://bugs.horde.org/ticket/7769#t54888 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 Wed, 12 Aug 2009 22:28:15 +0000 https://bugs.horde.org/ticket/7769#t55286 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 Wed, 12 Aug 2009 22:32:53 +0000 https://bugs.horde.org/ticket/7769#t55287 Fixed in CVS. Wed, 12 Aug 2009 22:33:45 +0000 https://bugs.horde.org/ticket/7769#t55288 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 Wed, 13 Jan 2010 00:10:22 +0000 https://bugs.horde.org/ticket/7769#t57597