Changes have been made in Git for this ticket:

Bug #8612: Automatically disable tidy.clean_output PHP setting

http://git.horde.org/diff.php/horde/lib/Test.php?rt=horde-git&r1=b36466d6d01527bf72649d6a2da6a5b77e2d582c&r2=72b8d57b0cd97055c6d69bf2a2659a304f4ea709
http://git.horde.org/diff.php/horde/lib/core.php?rt=horde-git&r1=a68fbe3eb4e44bfff12d4c2163ae33919075e52c&r2=72b8d57b0cd97055c6d69bf2a2659a304f4ea709

Changes have been made in Git for this ticket:

Bug #8612: Automatically disable tidy.clean_output PHP setting

http://git.horde.org/diff.php/horde/lib/Test.php?rt=horde-git&r1=b36466d6d01527bf72649d6a2da6a5b77e2d582c&r2=72b8d57b0cd97055c6d69bf2a2659a304f4ea709
http://git.horde.org/diff.php/horde/lib/core.php?rt=horde-git&r1=a68fbe3eb4e44bfff12d4c2163ae33919075e52c&r2=72b8d57b0cd97055c6d69bf2a2659a304f4ea709

Changes have been made in Git for this ticket:

Bug #8612: Automatically disable tidy.clean_output PHP setting

http://git.horde.org/diff.php/horde/lib/Test.php?rt=horde-git&r1=b36466d6d01527bf72649d6a2da6a5b77e2d582c&r2=746941ec3a009b6390275b9f42244a4b2246d7a9
http://git.horde.org/diff.php/horde/lib/core.php?rt=horde-git&r1=a68fbe3eb4e44bfff12d4c2163ae33919075e52c&r2=746941ec3a009b6390275b9f42244a4b2246d7a9

Done in Horde 3.3.7.

Changes have been made in CVS for this ticket:

Bug: 8612
Merge from git master 746941e
http://cvs.horde.org/diff.php/horde/lib/core.php?rt=horde&r1=1.26.6.17&r2=1.26.6.18&ty=u

Seems like a reasonable one to make sure is set properly in core.php then...

Sure - you can always change clean_output... but this really has 
nothing to do with this ticket.  This will be a problem with any 
non-html page served from horde.  Straight from the documentation, a 
giant warning:

Do not turn on tidy.clean_output if you are generating non-html 
content such as dynamic images.

Is this a setting we can configure to avoid this problem?

We found the solution: you simply have to change "tidy.clean_output" 
to "Off" in your global php.ini and the zip-file won't get corrupted 
anymore. A look at various versions of freebsd (namely 6.0, 7.0 and 
8.0) with a standard LAMP-installation showed up, that this parameter 
changes without comment (= no release notes entry; at least I didn't 
find one)...

Strange.
I have 2 machnines with identical versions of horde, imp installed 
(one on FBsd7 the other on FBsd8)
It works on the second one, but I have the corupted zip file errof on 
the first one.
Their zip.php files are ident ...

Strange.
I have 2 machnines with identical versions of horde, imp installed 
(one on FBsd7 the other on FBsd8)
It works on the second one, but I have the corupted zip file errof on 
the first one.
Their zip.php files are ident ...

After lots of debugging, I've found that the 0x0a character is added 
by the PHP header() function:



- If I remove the call to downloadHeaders function in view.php, I have 
no extra character.

- if I replace the call to downloadHeaders with only one header() call 
(content-length one for example), I do have the extra 0x0a character 
before $body.



In any case, the zip file generated by $horde_compress->compress(...) 
is OK (wrote it down to a file, and tested it successfully with zip -T)



What I've done, is setting the content-Length header with 
strlen($body)+1. Thus, I still have an extra character in the 
beginning of the zip file (which does not prevent winzip from openning 
it), but I do not miss the last byte of the zip file.



Does anyone have an Idea of why header() acts like this or should I 
open a bug on PHP bugtracker ?



Anyway, you can close this ticket, as it is not horde/imp related.



Thanks for your help.

Then you will need to find where that extra line break is coming from. 
  It isn't coming from either IMP's view.php or the Horde_Compress:: 
zip driver.



Horde_Compress::compress() sets the $contents variable to '' (the 
empty string).  On the first call to _addToZipFile(), the first data 
added to contents is $this->_fileHeader, which is "\x50\x4b\x03\x04".   
So that's not the issue.



view.php simply takes the output from compress and directly outputs 
it.  In the 1 line between the call to compress() and the echo call, 
there is no prepending of a linebreak.



you will need to trace on your system where the "\n" is coming from.

Of courde, the zip file I just provided is not as broken as expeted 
(just an extra byte at the beginning). Here is another one with two 
images inside. There is the same extra byte (0x0a) at the beginning, 
but zip can't even test it:

$ zip -T zip_attachements2.zip



zip error: Unexpected end of zip file (zip_attachements2.zip)

I confirm it does not work for me. I use Horde Groupware Webmail 
Edition 1.2.3. Here is a detailed version list :

     * Dimp: H3 (1.1.2)

     * Horde: 3.3.4

     * Imp: H3 (4.3.4)

     * Ingo: H3 (1.2.1)

     * Kronolith: H3 (2.3.1)

     * Mimp: H3 (1.1.1)

     * Mnemo: H3 (2.2.1)

     * Nag: H3 (2.3.2)

     * Turba: H3 (2.3.1)



The version of the file lib/Horde/Compress/zip.php is

   * $Horde: framework/Compress/Compress/zip.php,v 1.11.12.22 
2009/01/06 15:22:59 jan Exp $



I join a zip downloaded from imp (it should contain the 
horde-halfgear.png logo).



$ od -xc zip_attachement.zip|head

0000000    500a    034b    1404    0000    0800    7600    3e52    363b

          \n   P   K 003 004 024  \0  \0  \0  \b  \0   v   R   >   ;   6

0000020    2d6f    866d    000e    8100    000e    1200    0000    6800

           o   -   m 206 016  \0  \0 201 016  \0  \0 022  \0  \0  \0   h

0000040    726f    6564    682d    6c61    6766    6165    2e72    6e70

           o   r   d   e   -   h   a   l   f   g   e   a   r   .   p   n

0000060    0167    0e81    f17e    5089    474e    0a0d    0a1a    0000

           g 001 201 016   ~ 361 211   P   N   G  \r  \n 032  \n  \0  \0

0000100    0d00    4849    5244    0000    9b00    0000    5800    0608

          \0  \r   I   H   D   R  \0  \0  \0 233  \0  \0  \0   X  \b 006

Works for me.  Downloading a zip file with 21 attachments gets me this:



slusarz@schrute:~/Desktop$ zip -T test.zip

test of test.zip OK

When trying to download all attachments of an e-mail as zip file, the 
zip file is corrupted. The first thing I see is that the zip file 
begins with characters 0x0a, "P", "K". A regular zip file begins 
directly with "P", "K". Removing this first 0x0a character is not 
enough to repair the zip file.