Ticket #1484256 (closed Bugs: fixed)

Opened 20 months ago

Last modified 8 weeks ago

Big (more than ~1.8mb) attachments are failing to download to browser

Reported by: egor Owned by: till
Priority: 5 Milestone: 0.2-beta
Component: PHP backend Version: svn-trunk
Severity: normal Keywords:
Cc: tomek

Description

Steps to reproduce:

1. Open a mail in roundcube with 4mb attachment 2. Click on the attachment 3. The attachment is downloading

Results:

1. The size of the downloading file is not known to the browser 2. The download speed degrades until the download reaches about 1.6mb 3. At about 1.6mb downloading stops, server side closes connection

Expected results:

1. Content-length is supplied so that the browser and the user can be sure about the download consistency 2. Download speed is constant 3. Attach downloads fully.

Tested on:

1. The latest roundcube from svn 2. Different internet connections (all broadband, all direct, no proxy) 3. Different browsers 4. Different messages 5. Server: Linux, Apache 2.0.55, PHP 5.2.0

Please let me know if you need further input or repeatable test case.

Attachments

full-attachments.diff (1.0 kB) - added by mankytongue 20 months ago.

Change History

Changed 20 months ago by mankytongue

Changed 20 months ago by mankytongue

I was also having this problem, getting partially downloaded images and so on.

I looked into the download-attachment code and tweaked it a bit. The modifications I made work well in my situation, the size of the file is reported to the browser and the downloads are complete (and also faster but that may just be psychological, my code shouldn't have any effect on that).

The script requires the use of a tmpfile, so there might be security implications if the files contain sensitive information. The web server (or owner of script process) needs write access to /tmp, but any path will do, even the 'temp' directory in the roundcube root.

I've attached the patch, which I wrote and applied against r500.

Changed 20 months ago by egor

Thank you very much!

Changed 20 months ago by mankytongue

  • status changed from new to closed
  • resolution set to fixed

Changed 20 months ago by mankytongue

  • cc thomasb added
  • status changed from closed to reopened
  • resolution deleted

Request for modification/adaptation of the patch and perhaps to be included in the trunk.

Changed 8 months ago by till

  • owner set to till
  • status changed from reopened to new
  • milestone set to 0.1-stable

Changed 8 months ago by tomekp

try

ini_set('zlib.output_compression', false);

Changed 8 months ago by till

  • milestone changed from 0.1-stable to 0.1.1

I can't reproduce this, my zlib.output_compression is also off.

I added it to check.php and to .htaccess in r1097.

The rest ist postponed to 0.1.1.

Changed 8 months ago by till

  • cc tomek added; thomasb removed

Changed 7 months ago by till

  • milestone changed from 0.1.1 to 0.2-beta

Changed 8 weeks ago by alec

  • status changed from new to closed
  • resolution set to fixed
  • component changed from Client Scripts to PHP backend

Added Content-Length (from $part->size) in r1670.

Changed 8 weeks ago by thomasb

Fix of r1670 did not work as expected. We now disabled time limit for large downloads in r1673 which will hopefully fix this isssue.

Note: See TracTickets for help on using tickets.