415449 - Negative (0-12:0-42) time remaining when the file is bigger than the size announced by the HTTP server

Status: UNCONFIRMED

(Toolkit :: Downloads API, defect)

Description

[Sabrina Dubroca]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)

When downloading a file on a server which announces a size smaller than the actual size of the file, a negative "time remaining" is displayed

Reproducible: Didn't try

Steps to Reproduce:
1. start downloading a file from a server announcing a wrong size
2. download more than the announced size
Actual Results:  
"53 of 49.2 MB at 4.4 KB/sec; 0-13:0-36 remain" text shown under the download progress bar

Expected Results:  
Maybe announce an "unknown time remaining"

Comment 1

[Shawn Wilsher :sdwilsh]

I need one of two things from you:
1) The url to a server which does this
2) Does this happen in an official build (aka, not iceweasle)

biesi - how common do you think it is for a server to send us the wrong size, and should we even care?

Comment 2

[Jason Quinn]

Shawn, I think this is part of a larger problem. 

It seems like the downloads manager's progress monitor non-gracefully handles the downloading of some compressed files like ".gz" files when the browser does the decompression automatically. For example, try downloading some of the ".ps" and ".pdf" files from this site ( http://xxx.lanl.gov/list/astro-ph/new ) and watch the progress monitor in the downloads manager. The site sends the file in compressed format as can be confirm by looking at the http headers. The progress monitor, however, increments until it reaches the uncompressed size but says it is "out of" the compressed size. This is ratio is larger than one and therefore confuses the user. It also looks like the uncompressed file was transfered rather than the compressed file. Opera seems to suffer from a similar problem.

The original poster more likely ran into the situation I described above than an actual incorrect content-length http header. The later case is a server-side problem, not a browser problem, and I would argue that a work-a-round should not be created anyway.

Comment 3

[Shawn Wilsher :sdwilsh]

That would likely be a network bug then, and not one with the download manager.