6.0.0-RC7
6/29/26

[#4912] normally downloaded/zipped attachments have two extra lines at the beginning
Summary normally downloaded/zipped attachments have two extra lines at the beginning
Queue IMP
Queue Version 4.1.3
Type Bug
State Not A Bug
Priority 2. Medium
Owners
Requester kajtzu (at) basen (dot) net
Created 1/17/07 (7103 days ago)
Due
Updated 1/17/07 (7103 days ago)
Assigned
Resolved 1/17/07 (7103 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
1910 Chuck Hagenbuch State ⇒ Not A Bug
 
610 kajtzu (at) basen (dot) net Comment #5 Reply to this comment
Oh boy.... Figured out what the problem was. I had written an 
_horde_hook_preauthenticate function in hooks.php. There was exactly 
one line before <?php and one line after ?> resulting in two extra 
lines being printed out.



My bad, sorry for wasting bandwidth.
1510 kajtzu (at) basen (dot) net Comment #4 Reply to this comment
If I put an echo statement in lib/IMP.php:1363 before



$reason = $auth_imp->authenticate();



it gets printed at the top of the stream



if I put an echo statement after that statement it gets printed after 
the two empty lines.




129 kajtzu (at) basen (dot) net Comment #3 Reply to this comment
This actually applies also when saving the whole message with "Save 
as" (between Message Source and Print). There are two new lines (0x0A) 
before the line starting with From someone@somewhere ..
129 kajtzu (at) basen (dot) net Comment #2 Reply to this comment
With LiveHTTPHeaders in FF 2.0.1 the request is as follows:



https://www.bnsvcs.net/horde/services/download/?module=imp&thismailbox=INBOX&index=38&mailbox=INBOX&actionID=download_attach&id=2&mimecache=5e5fd7d3aaa757960ca052aebe5f12ec&fn=%2FHoorde-2.png



GET 
/horde/services/download/?module=imp&thismailbox=INBOX&index=38&mailbox=INBOX&actionID=download_attach&id=2&mimecache=5e5fd7d3aaa757960ca052aebe5f12ec&fn=%2FHoorde-2.png 
HTTP/1.1

Host: www.bnsvcs.net

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; 
rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cookie: horde_sidebar_expanded=true; Horde=k6dsneac539f3u3fpc3qf30jn3; 
auth_key=6e2b7abcdd9f15b17022a1b6eac4f815; 
imp_key=5b74886d19bd9d9995d2cb920c5dc5d1



HTTP/1.x 200 OK

Date: Wed, 17 Jan 2007 20:53:32 GMT

Server: Apache

X-Powered-By: PHP/5.2.0

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

content-disposition: attachment; filename="Hoorde-2.png"

Content-Length: 175266

Connection: close

Content-Type: image/png

----------------------------------------------------------



But the file downloaded is actually 175268 (+2 bytes) long.



Another file is 93118 bytes long but when downloaded through IMP 93120 
(again +2 bytes).




88 kajtzu (at) basen (dot) net Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ normally downloaded/zipped attachments have two extra lines at the beginning
Queue ⇒ IMP
Reply to this comment
This is a fresh environment with horde 3.1.3, imp 4.1.3, apache 2.2.3, 
php 5.2.0 with no modifications to the source code.



When downloading attachments something appends two empty lines on top 
effectively corrupting the attachment. Removing these two lines makes 
the attachment work normally. I think this happens when PHP wants to 
print out something that is suppressed but I have absolutely no idea 
on how to figure out how this happens. The attachments are not corrupt 
and work fine downloaded through a normal imap client (outlook, 
thunderbird, Mail.app, etc.)



Any pointers?


Saved Queries