Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#1484198 closed Bugs (fixed)

Attachment handling

Reported by: crichardson Owned by:
Priority: 5 Milestone: 0.1-rc1
Component: Core functionality Version: git-master
Severity: normal Keywords: attachment pdf doc excel
Cc:

Description

System specs
OS: Windows
IE6 and Firefox 1.5.0.8
Acrobat: 7
Office 2003

PDF:

Firefox: Opens a new window saying Loading data.. and trys to open it in acrobat which inturn says the file is damaged and could not be repaired.

IE6: Opens a new window saying Loading data.. then says "to help protect your security, Internet Explorer blocked this site from downloading files to your computer click here for options"

clicking there gives you the option to download it which seems to work but then when you goto open it after the download is complete acrobat says file is damaged and could not be repaired.

Doc:

Firefox: saves the file and opens it correctly

IE6: Gives option to save or open. if you chose
open: it says the file could not be found.
save: if you save it first it works

Excel has similar results as doc

Attachments (1)

PATCH_get.inc (1.6 KB) - added by crichardson 6 years ago.
patch to /program/steps/mail/get.inc

Download all attachments as: .zip

Change History (11)

comment:1 Changed 6 years ago by crichardson

Opera 8.5.1 has same effects as firefox

comment:2 Changed 6 years ago by jpingle

Watching the connection via tcpflow, the server produces the following output when a PDF is viewed as an attachment:

View Attachment:

HTTP/1.1 200 OK
Date: Fri, 05 Jan 2007 01:12:13 GMT
Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.0 with Suhosin-Patch SVN/1.4.2 mod_fastcgi/2.4.2
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: inline; filename="ThePhotographersRight.pdf"
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/pdf

39
%PDF-1.2
<rest of file here>

I confirmed that in IE and Firefox the whole file is received by the browser, yet for whatever reason the plugin does not fire in IE.

Here are the results when the same file is requested from the same server after uploading and requesting it directly:

HTTP/1.1 200 OK
Date: Fri, 05 Jan 2007 01:33:31 GMT
Server: Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.0 with Suhosin-Patch SVN/1.4.2 mod_fastcgi/2.4.2
Last-Modified: Sun, 30 Jul 2006 12:11:49 GMT
ETag: "1152d-d705-7338cb40"
Accept-Ranges: bytes
Content-Length: 55045
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/pdf

%PDF-1.2
<rest of file here>

Not sure what exactly IE is choking on, but the headers are a little different. The file content is the same regardless of which browser requested the attachment.

comment:3 Changed 6 years ago by jpingle

This appears to be due to a missing content-length header. PHP enables Transfer-Encoding: chunked and inserts chunk data in at various places (like that "39" in the first header set)

If the "Content-Length:" header is set with a valid length, it should work.

It looks as though in the past RC sent a length header, but it was incorrect and caused attachment downloads to stall (Ticket #1483864)

Looks like it may need some more work...

comment:4 Changed 6 years ago by jpingle

It seems that the "size" of the attachment that RC knows about is the size before it is decoded. It is decoded and printed in one step, and RC never has a full copy of the attachment in memory. Because it is never fully in memory, RC has no way to know its true size, and thus has no way of knowing what size to send in the content-length header to make IE happy.

The downside of decoding and then printing is that you'd be bound by the memory limits of PHP for the size of an attachment than can be received. I seem to recall that currently this is only factor is sending attachments.

comment:5 Changed 6 years ago by jpingle

Here's an idea: There could be a threshold value such that attachments under <x>KB will be decoded in memory and the proper content length given. For others, the viewer could be disabled and a download link forced.

Changed 6 years ago by crichardson

patch to /program/steps/mail/get.inc

comment:6 Changed 6 years ago by crichardson

  • Resolution set to fixed
  • Status changed from new to closed

After some looking arround at some stuff we have that does it correctly I have been able to get it to work properly against the current svn after applying this patch. it solved all my problems related to opening pdfs, excel, word ect

comment:7 Changed 6 years ago by crichardson

this ticket i think is related and may also be able to be closed but will wait for others to test it
http://trac.roundcube.net/trac.cgi/ticket/1484004

comment:8 Changed 6 years ago by crichardson

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:9 Changed 6 years ago by crichardson

Reopened to Make sure it gets testing and input

comment:10 Changed 6 years ago by thomasb

  • Milestone set to 0.1-rc1
  • Resolution set to fixed
  • Status changed from reopened to closed

Applied patch in [5a6ad209]

Note: See TracTickets for help on using tickets.