6.0.0-git
2019-03-23

[#7769] Linux Funambol 0.7+ on thunderbird gives send http request error
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 2008-12-11 (3754 days ago)
Due
Updated 2010-01-13 (3356 days ago)
Assigned 2009-07-10 (3543 days ago)
Resolved 2009-08-12 (3510 days ago)
Milestone 3.3.5
Patch No

History
2009-08-12 22:33:45 Jan Schneider Comment #18
State ⇒ Resolved
Reply to this comment
Fixed in CVS.
2009-07-11 17:58:51 Jan Schneider Milestone ⇒ 3.3.5
 
2009-07-10 03:01:08 Chuck Hagenbuch Comment #15
State ⇒ Assigned
Reply to this comment
Looks like we have a culprit then. Back to Jan...
2009-07-10 02:32:29 devendralaulkar (at) yahoo (dot) com Comment #14
New Attachment: horde_debug_2.log Download
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


2009-07-10 01:26:22 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.
2009-07-10 01:03:27 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)






2009-07-10 00:10:29 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.
2009-07-09 00:59:41 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.
2009-07-09 00:11:56 devendralaulkar (at) yahoo (dot) com Comment #9
New Attachment: horde.log Download
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.
2009-04-20 08:37:45 Jan Schneider State ⇒ No Feedback
 
2009-04-05 20:46:13 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.
2009-03-30 12:51:47 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
Priority ⇒ 2. Medium
 
2009-03-27 09:25:30 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.
2009-03-26 00:22:40 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
2009-03-25 16:48:28 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?
2009-03-25 16:29:05 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
2008-12-11 15:48:03 Jan Schneider Comment #3
State ⇒ Not A Bug
Priority ⇒ 1. Low
Reply to this comment
Sounds like a Funambol bug then.
2008-12-11 15:30:57 highvoltspam (at) gmail (dot) com Comment #2 Reply to this comment

[Show Quoted Text - 16 lines]
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)
2008-12-11 01:17:44 highvoltspam (at) gmail (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ Linux Funambol 0.7+ on thunderbird gives send http request error
Queue ⇒ Synchronization
Milestone ⇒
Patch ⇒ No
New Attachment: syncmllog.tar.gz Download
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 ?

Saved Queries