[Tickets #602] messages displayed after ingo blacklist/whitelist are displayed as garbage

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=602
-----------------------------------------------------------------------
 Ticket     | 602
 Updated By | Michael Slusarz <slusarz at mail.curecanti.org>
 Summary    | messages displayed after ingo blacklist/whitelist are displayed as garbage
 Queue      | Ingo
 Version    | RELENG_1
 State      | Assigned
 Priority   | 1. Low
 Type       | Bug
 Owners     | Michael Slusarz
-----------------------------------------------------------------------


Michael Slusarz <slusarz at mail.curecanti.org> (2004-09-20 13:45) wrote:

I'm beginning to see the problem (I think).  Namely, ingo uses
Horde::compressOutput() to start page compression but this will only work if
all other applications use that function to start page compression.  No
other app does (it was only added to Horde in 2.2).  Therefore, if an app
enables compression without calling Horde::compressOutput(), then calls Ingo
via an API, Ingo will compress the output again - this is resulting in the
garbage that you are seeing.

So quick answer - there is really no way to reliably enable compression in
ingo in RELENG_1 because there is no way to tell if the output in the buffer
that has already been compressed, at least with the versions of PHP that
Horde 2.x supports (namely, ob_list_handlers() is not available until PHP
4.3.0).  Thus it appears our only solution is to remove page compression
from ingo.

So try what I just committed.  Hopefully this works.