Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#1484256 closed Bugs (fixed)

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: git-master
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 (1)

full-attachments.diff (989 bytes) - added by mankytongue 6 years ago.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by mankytongue

comment:1 Changed 6 years 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 [ff52bee1].

comment:2 Changed 6 years ago by egor

Thank you very much!

comment:3 Changed 6 years ago by mankytongue

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

comment:4 Changed 6 years ago by mankytongue

  • Cc thomasb added
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:5 Changed 5 years ago by till

  • Milestone set to 0.1-stable
  • Owner set to till
  • Status changed from reopened to new

comment:6 Changed 5 years ago by tomekp

try

ini_set('zlib.output_compression', false);

comment:7 Changed 5 years 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 [342db9d0].

The rest ist postponed to 0.1.1.

comment:8 Changed 5 years ago by till

  • Cc tomek added; thomasb removed

comment:9 Changed 5 years ago by till

  • Milestone changed from 0.1.1 to 0.2-beta

comment:10 Changed 5 years ago by alec

  • Component changed from Client Scripts to PHP backend
  • Resolution set to fixed
  • Status changed from new to closed

Added Content-Length (from $part->size) in [2c6fa933].

comment:11 Changed 5 years ago by thomasb

Fix of [2c6fa933] did not work as expected. We now disabled time limit for large downloads in [0ced2b9a] which will hopefully fix this isssue.

Note: See TracTickets for help on using tickets.